Використання хинта Index
Підказка оптимізатору використовувати конкретний індекс корисна, коли необхідно змусити SQL Server використовувати саме цей індекс, і якщо саме з цим індексом підвищиться ефективність запиту. Використовувати такий хинт краще, коли Ви точно знаєте, що SQL Server не вибирає оптимальний для запиту індекс, і необхідно допомогти SQL Server вибрати правильний індекс. У хинти потрібно вказати id індексу або його ім'я. Нижче представлений приклад запиту, в якому підставляється id для одного індексу:
Використання id рівного 0, змусить SQL Server використовувати сканування кластерного індексу, якщо він існує. Якщо кластерного індексу немає, тоді буде виконано просте сканування таблиці. Нижче представлений приклад запиту, в якому замість id використовується ім'я індексу:
Хінт порядку об'єднання
Порядок об'єднання в SQL Server для кожної таблиці в реченні FROM, дуже сильно впливає на те, як будуть виконуватися запит або збережена процедура. Об'єднання таблиць в неправильному порядку може істотно збільшити час виконання запиту. Якщо Ви вважаєте, що SQL Server вибрав не оптимальний порядок об'єднання таблиці, Ви повинні знайти кращий порядок об'єднання і вказати його хинти. Для представлених нижче двох невеликих прикладів буде корисно розглянути плани їх виконання, щоб побачити запропонований порядок об'єднання таблиць, обраний SQL сервером в обох випадках. Ви можете подивитися плани в Query Analyzer або клацнути по відповідному посиланню, зазначеної нижче у цьому розділі. Перший запит показує те, що виходить, коли таблиці об'єднані не оптимальне.
Тепер виконайте другий запит (який є тим же самим запитом, але без використання хинта).
Коли хинт видалений з запиту, об'єднання таблиць буде виконано в іншому порядку. Порядок, який використовує SQL Server без хинта, виявиться краще. Він починається з таблиці titleauthor, яка об'єднується з таблицею titles. Після цього слід об'єднання з таблицею roysched з результатом об'єднання двох інших таблиць.
Швидким способом побачити те, який з наведених вище запитів працює швидше, є виконання їх обох в одному вікні Query Analyzer, і спільний розгляд їхніх планів виконання. Так Ви побачите, чому другий запит працює швидше, ніж перший.
Клацніть по цьому посиланню: План виконання першого запиту
Клацніть по цьому посиланню: План виконання другого запиту
Як Ви бачите, в першому запиті join таблиць titles і roysched дає в результаті 86 записів. Ці 86 записів використовуються для наступного вкладеного циклу з join. Тут ми маємо 123 записи, які становлять результат, представлений посиланням вище. У другому запиті, перший join таблиць titleauthor і titles дає вже в результаті 25 записів. Крім того, відсутні проміжні кроки перед об'єднанням з третьої таблицею з 25 записів, після чого виходить результуючий набір з 123 записів.
Другий запит виконався швидше, тому що він має справу з меншою кількістю рядків. Число рядків, які були задіяні, сильно залежить від порядку об'єднання таблиць між собою. Це демонструє важливість порядку об'єднання таблиць. SQL Server розглядає досить багато впливають на об'єднання факторів, перед тим, як визначити, який порядок оптимально використовувати при об'єднанні таблиць. Це зазвичай: число рядків в таблиці, первинні ключі, індекси, число процесорів і поточне завантаження сервера, а іноді тільки деякі з цих факторів. Якщо SQL Server раптом розмістить таблиці для join в неправильному порядку, спробуйте виправити цю проблему, визначивши більш оптимальний порядок, використовуючи хинт порядку об'єднання.
Хінт nolock для таблиць
Пропозиція WITH (Nolock) завжди поміщається відразу після імені таблиці або її псевдоніма.
Представлений нижче запит демонструє, як Ви можете вибирати дані без хинта nolock і переглядати ці даних до того, як вони будуть зафіксовані при використанні хинта Nolock. Виконайте наступний запит в окремому вікні Query Analyzer:
Цей запит встановить виняткову блокування на таблицю titles через що неможливо буде виконувати в ній зміни, доки Ви не виконуєте команду COMMIT TRANSACTION. Тепер в іншому вікні Query Analyzer, підключившись до того ж сервера, виконайте наступний запит:
Не соромтеся перервати виконання цього запиту, коли Вам набридне чекати результат. Ви його ніколи не отримаєте, доки Ви не закриєте інше вікно або не буде завершено модифікацію, виконавши команду завершення транзакції. SQL Server не дозволить Вам побачити дані, поки ця операція не буде завершена або НЕ відкотитися назад, тому що за замовчуванням буде запропонована виняткова блокування. Щоб обійти це, Ви можете змінити ваш запит, щоб він виглядав наступним чином:
Використання хинтов в ваших запитах має сенс хоча б тому, що Microsoft включив їх використання в набір можливостей SQL Server. Однак, використання більшості хинтов має бути обмежена, за винятком хіба що хинта, який описаний в третьому прикладі. Намагатися підвищити ефективність за допомогою хинта можна тільки тоді, коли не може бути знайдено інше рішення.