SQL Server, Как сравнить скорости простых запросов

Question

У меня большой запрос, и я пытаюсь улучшить его по частям, однако из-за механизма кэширования и простоты кодов t-sql у меня нет надежной среды для тестирования скоростей. Все запросы о скоростях, которые я пытаюсь улучшить, длятся около 1 или 2 секунд, поэтому я не вижу четкой разницы. И создание фиктивных данных для каждого сравнения занимает слишком много времени. Что вы предлагаете мне сделать? Я использую базу данных своей компании, поэтому каждый раз удаление кеша может быть вредным.

Edit: Прочитав все комментарии, я немного поработал, и у меня появилась идея. Но, глядя на все эти значения в статистике, это именно то, что я хочу?

Вот проблемы, с которыми я столкнулся:

План выполнения: Сначала я выполнил несколько запросов и посмотрел на План выполнения, вверху - Стоимость запроса (относительно пакета). Я не смог получить значение, отличное от 0,00%. Даже мой запрос длится более 1 минуты. Единственное, что я получаю, это 0,00%. А под графиками все значения 0%

Статистика БД . Сейчас я тестирую два запроса. Одним из них является

SELECT * FROM My_TABLE / * ГДЕ
my_primarykey LIKE "% ht_atk%" * /

И второй вариант - бесплатная версия с комментариями.

SELECT * FROM My_TABLE ГДЕ
my_primarykey LIKE '% ht_atk%'

Вот мои результаты из БД Статистика, первый запрос:.

Application Profile Statistics      
  Timer resolution (milliseconds)   0   0
  Number of INSERT, UPDATE, DELETE statements   0   0
  Rows effected by INSERT, UPDATE, DELETE statements    0   0
  Number of SELECT statements   2   2
  Rows effected by SELECT statements    16387   15748,4
  Number of user transactions   7   6,93182
  Average fetch time    0   0
  Cumulative fetch time 0   0
  Number of fetches 0   0
  Number of open statement handles  0   0
  Max number of opened statement handles    0   0
  Cumulative number of statement handles    0   0

Network Statistics      
  Number of server roundtrips   3   3
  Number of TDS packets sent    3   3
  Number of TDS packets received    252 242,545
  Number of bytes sent  868 861,091
  Number of bytes received  1,01917e+006    981160

Time Statistics     
  Cumulative client processing time 0   0,204545
  Cumulative wait time on server replies    25  10,0455

Второй запрос:

Application Profile Statistics      
  Timer resolution (milliseconds)   0   0
  Number of INSERT, UPDATE, DELETE statements   0   0
  Rows effected by INSERT, UPDATE, DELETE statements    0   0
  Number of SELECT statements   2   2
  Rows effected by SELECT statements    14982   15731,3
  Number of user transactions   5   6,88889
  Average fetch time    0   0
  Cumulative fetch time 0   0
  Number of fetches 0   0
  Number of open statement handles  0   0
  Max number of opened statement handles    0   0
  Cumulative number of statement handles    0   0

Network Statistics      
  Number of server roundtrips   3   3
  Number of TDS packets sent    3   3
  Number of TDS packets received    230 242,267
  Number of bytes sent  752 858,667
  Number of bytes received  932387  980076

Time Statistics     
  Cumulative client processing time 1   0,222222
  Cumulative wait time on server replies    8   10

Каждый раз, когда я выполняю, значения меняются случайным образом, и я не могу понять, какой запрос быстрее

Наконец, когда я это сделаю:

УСТАНОВИТЬ ВРЕМЯ СТАТИСТИКИ НАСТРОЙКА СТАТИСТИКИ IO ON

Для обоих запросов результаты одинаковы.

Таблица 'my_TABLE'. Сканирование 1, логическое чтение 682, физическое чтение 0, чтение с опережением 0.

Итак, я снова не смог сравнить два запроса. как интерпретировать результаты? Я смотрю в неправильном месте. Как я могу сравнить эти два простых запроса выше?

Answer 1

Запустите set statistics time on и set statistics io on, затем выполните большой запрос в текстовом режиме. Вы можете поместить несколько отпечатков после каждой части запроса, который хотите оптимизировать.

Вы получите строки вроде:

Table 'Table'. Scan count 1, logical reads 10, physical reads 0, read-ahead reads 0, lob    logical reads 387, lob physical reads 0, lob read-ahead reads 0.

Попытайтесь поместить некоторые данные в таблицы и проверьте количество сканирований и логическое чтение на наличие больших чисел.

Вы также можете проверить фактический план выполнения и выполнить поиск любого сканирования кластерного индекса. Это может указывать на то, что в некоторой таблице отсутствует индекс.

Answer 2

Используйте анализатор запросов , чтобы узнать дорогие части вашего запроса (это зависит от статистики БД, поэтому используйте репрезентативные данные).

Это позволит вам сосредоточиться на тех частях, которые вы должны оптимизировать.

Попытка рассчитать время с помощью секундомера или посмотреть, сколько времени потребуется, чтобы результаты вернулись в SSMS, будет в лучшем случае догадкой.

Answer 3

В анализаторе запросов перейдите в раздел Запрос> Включить фактический план выполнения и Запрос> Включить статистику клиента.

Используйте план выполнения, чтобы определить наиболее дорогостоящие части вашего запроса. Если вы наведете указатель мыши или щелкнете по любому из узлов, он покажет вам всю группу статистики. Попробуйте посмотреть, можете ли вы переработать объединение или фильтр, чтобы уменьшить количество возвращаемых строк.

Используйте статистику клиента для сравнения двух запросов. Каждый раз, когда вы запускаете запрос, он добавляет новый столбец на страницу статистики клиента. Вы хотите посмотреть на нижнюю группу: Статистика по времени.

Я знаю, что некоторые из них очевидны, но вот несколько общих советов по снижению нагрузки: -Возврат только те столбцы, которые вам нужны. Иногда люди возвращают все столбцы или столбцы идентификаторов, которые они используют для кодирования, но конечному пользователю это не нужно. -Для каждой таблицы - уменьшить количество возвращаемых строк. -Попробуйте не использовать временные таблицы, когда вам не нужно. Это вызывает «двойное падение» или многократный запрос одной и той же очень большой таблицы.

Answer 4

, как сказал @affan, лучший способ - использовать информацию, предоставленную планом выполнения. но вы всегда можете настроить простой счетчик с кодом вроде

IF @debug > 0 BEGIN
    DECLARE @now DATETIME;
    SET @now = CURRENT_TIMESTAMP;
END

и

IF @debug > 0 BEGIN
    SELECT DATEDIFF(ms,@now,CURRENT_TIMESTAMP)/1000.0 AS Runtime;
END

Answer 5

Хороший способ - тоже увидеть исполнение. Он много говорит о том, как будет выполняться запрос и что занимает большую часть времени. Вы даже можете решить создать индексы на этой основе. Это очень полезно, особенно для больших запросов. SQLServer большую часть времени находит лучший из возможных способов выполнения запроса, но вы можете улучшить его, предоставив ему индекс по полю, который используется в операторах WHERE и JOIN. Если вы не можете прочесть простое выполнение, похожее на график с приблизительной стоимостью и временем, вы можете прочитать об этом в MSDN.