Настройка производительности запросов


12

Когда вы закончите написание запроса / хранимой процедуры / функции, какой самый информативный способ быстро получить некоторые параметры производительности? Вы запускаете запрос и просматриваете фактический план выполнения? Если да, что вы ищете? Очевидно, что сканирование таблиц / индексов является хитом, но что еще?

Ответы:


8

Для быстрой оценки получите план выполнения из SSMS и в Plan Explorer .

  • Просмотрите самые дорогие операции для чего-нибудь неожиданного. Сортировка, рабочие таблицы, неподходящие операторы соединения (например, вложенный цикл, в котором ожидается слияние или хэш).
  • Посмотрите на количество строк на каждом этапе плана, находятся ли они в широком диапазоне, который вы ожидаете увидеть?
  • Посмотрите на оценочные и фактические строки. Если ваши данные близки к оценкам, скорее всего, у вас есть хороший план. Если есть большие различия, выясните, почему (например, статистика отсутствует или устарела).
  • Оцените потенциальные проблемы с прослушиванием параметров. Ищите области, где мощность может варьироваться, и проверяйте диапазон входных параметров.

Имеется множество свободно доступных справочных материалов, планы выполнения SQL Server от Гранта Фитчли - хорошее начало. Я также нашел очень полезными сообщения в блоге Джо Чанга и электронную книгу о плане выполнения.


5

В основном все, что я делаю, - это просто запускаю запрос и выясняю, как он выполняется на реальных данных. Если есть проблема, тогда я смотрю на планы выполнения.

Что касается планов выполнения, у Брэда МакГи есть интересная статья на эту тему.

В нем он говорит:

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

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, dont include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Не всегда возможно избежать этого, но чем больше вы можете избежать их, тем быстрее будет выполняться запрос.


0
SET STATISTICS IO ON

Как правило, «количество логических операций чтения» должно быть как можно ниже. Несколько страниц, затронутых для выполнения запроса, тем лучше план, поскольку он будет (как правило) быстрее, тем меньше будет влияние на процессор, оперативную память и дисковый ввод-вывод.

Это поможет вам, когда изменение индексов или перефакторинг SQL действительно помогает. Просмотр «времени исключения в миллисекундах» будет отличаться даже при одном и том же SQL-запросе и плане запроса - логические чтения останутся согласованными для любого данного плана запроса.

Также «физическое чтение» должно быть очень низким (и быть нулевым и оставаться нулевым для последующих исполнений). Если этого не происходит, посмотрите на использование памяти SQL Server (срок службы страницы и т. Д.).


Но для запросов, которые выполняются, когда их нет в кэше запросов, физические чтения будут больше нуля, верно? Я имею в виду, что вы не всегда можете обойти это, поскольку не все запросы (особенно специальные) кэшируются. Я прав?
Томас Стрингер

@ Surfer513, чтобы позаботиться о кэшировании данных, вы можете выполнить команду CHECKPOINT, а затем DBCC DROPCLEANBUFFERS, чтобы очистить пул буферов (кэш данных). Обратите внимание, что это очистит буферы для всех, поэтому используйте их соответствующим образом (в тестовых системах).
СтэнлиДжонс

@StanleyJohns, почему вы хотите очистить кеш данных / запросов?
Томас Стрингер

Таким образом, физический ввод-вывод будет одинаковым каждый раз, обеспечивая согласованность, необходимую для тестирования. Это поможет в тонкой настройке запроса.
СтэнлиДжонс

Я бы проигнорировал физическую статистику ввода-вывода, поскольку она находится под контролем базовой инфраструктуры и будет включать буферизацию SAN и OS. Логические операции ввода-вывода - это мера объема работы, которую должен выполнить оператор SQL. Если SQL выполняет менее логичный ввод-вывод, он выполняет меньше работы.
Парень
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.