Налаштування ефективності запитів

Коли ви закінчите писати запит / збережену процедуру / функцію, який найбільш інформативний спосіб швидко отримати деякі параметри продуктивності? Ви запускаєте запит і переглядаєте фактичний план виконання? Якщо так, то які речі ви шукаєте? Очевидно сканування таблиці / індексу - це біт-хіти, але що ще?

Для швидкої оцінки дістаньте план виконання із SSMS та перейдіть до Провідника плану .

• Перегляньте найдорожчі операції на предмет нічого несподіваного. Сорти, робочі таблиці, невідповідні оператори приєднання (наприклад, вкладений цикл, де очікується злиття або хеш).
• Подивіться на кількість рядків на кожному етапі плану, чи вони в широкому діапазоні від того, що ви очікували побачити?
• Подивіться на оціночні та фактичні рядки. Якщо фактичні факти близькі до оцінок, швидше за все, у вас хороший план. Якщо є великі відмінності, з’ясуйте, чому (наприклад, відсутні статистичні дані та / або застарілі).
• Оцініть потенціал для проблем нюху параметрів. Шукайте області, де кардинальність може змінюватись, і перевіряйте набір вхідних параметрів.

Багато вільно доступних довідкових матеріалів там, Плани виконання 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

Як правило, "кількість логічних читань" повинна бути якомога меншою. Кілька сторінок торкнулися для завершення запиту, чим краще план, оскільки він буде (як правило) швидшим, тим менший вплив на процесор, оперативну пам’ять та диск IO.

Це допоможе вам змінити індекси або повторний факторинг SQL насправді допомагає. Дивлячись на "мілісекундний час вилучення", буде змінюватися навіть той самий план SQL та запитів - логічні зчитування залишатимуться послідовними для будь-якого заданого плану запитів.

Також "фізичні показання" повинні бути дуже низькими (і бути нульовими та залишатися нульовими для наступних страт). Якщо цього не зробити, перегляньте використання пам'яті SQL Server (життя сторінки тощо).