Підвищення ефективності за рахунок використання підказок оптимізатору, Мова запитів SQL, Бази
Використання хінту 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. Після цього слід об'єднання з таблицею рейок,що з результатом об'єднання двох інших таблиць. Швидким способом побачити те, який із наданих вище запитів працює швидше, є виконання їх обох в одному вікні 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. Однак, використання більшості хінтів має бути обмежене, за винятком хіба що хінта, описаного в третьому прикладі. Намагатися підвищити ефективність за допомогою хінт можна тільки тоді, коли не може бути знайдено інше рішення.