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

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

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

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

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

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

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

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

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

* 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, don’t 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? 

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

SET STATISTICS IO ON

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

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

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