1. Щоб оптимізувати запит, слід уникати сканування повної таблиці і спочатку розглянути можливість створення індексу стовпців, які відповідають за where і по.
2. Намагайтеся уникати судження про нульові значення щодо полів у клаузі where, інакше це призведе до того, що рушій відмовиться від використання індексів і виконає повне сканування таблиці, наприклад:
Виберіть id з T, де NUM дорівнює нулю
Ви можете встановити значення за замовчуванням 0 на num, переконатися, що в стовпці num у таблиці немає null-значення, і потім зробити запит так:
Виберіть id з T, де num=0
3. Намагайтеся уникати використання операторів != або <> у клаузі where, інакше рушій відмовиться від використання індексів і виконає повне сканування таблиці.
4. Варто уникати використання OR у клаузі where для об'єднання умови, інакше це призведе до того, що рушій припинить використання індексів і виконає повне сканування таблиці, наприклад:
Виберіть ID з T, де num=10 або num=20
Ви можете поставити запит так:
Виберіть ID з T, де num=10
Union All
Виберіть ID з T, де num=20
5.in і не всередині слід використовувати обережно, інакше це призведе до повного сканування столу, наприклад:
Виберіть ID з T, де num in(1,2,3)
Для неперервних значень не використовуйте in, якщо можна поміж:
Виберіть ID з T, де NUM від 1 до 3
6. Наступний запит також призведе до повного сканування таблиці:
Виберіть ID з T, де ім'я на кшталт '%abc%'
Щоб підвищити ефективність, розгляньте повнотекстовий пошук.
7. Якщо ви використовуєте параметр у клаузі «where», це також спричинить повне сканування таблиці. Оскільки SQL розв'язує локальні змінні лише під час виконання, але оптимізатор не може відкласти вибір планів доступу на час виконання; Його потрібно вибрати під час компіляції. Однак, якщо план доступу встановлено під час компіляції, значення змінної залишається невідомим і тому не може використовуватися як вхідний елемент для вибору індексу. Наступні заяви будуть відскановані повністю:
Виберіть ID з T, де num=@num
Ви можете змусити запит використовувати індекс замість цього:
Виберіть id з T з (index(index(індексна назва)), де num=@num
8. Намагайтеся уникати вираження полів у клаузі where, що призведе до того, що рушій відмовиться від використання індексів на користь сканування повної таблиці. Наприклад:
Виберіть ID з T, де NUM/2=100
слід змінити на:
Виберіть ID з T, де num=100*2
9. Намагайтеся уникати виконання функційних операцій на полях у клаузі where, що призведе до того, що рушій відмовиться від використання індексів на користь повного сканування таблиці. Наприклад:
Виберіть id з T, де substring(name,1,3)='abc' --Name ID, що починається з abc
Виберіть id з T, де Datediff(Day,createdate,'2005-11-30')=0--'2005-11-30' генерується id
слід змінити на:
Виберіть ID з T, де ім'я на кшталт 'abc%'
Виберіть ID з t, де createdate>='2005-11-30' та createdate<'2005-12-1'
10. Не виконуйте функції, арифметичні операції чи інші операції вираження ліворуч від "=" у клаузі where, інакше система може неправильно використати індекс.
11. При використанні індексного поля як умови, якщо індекс є складеним, то перше поле в індексі має використовуватися як умова, щоб система використовувала індекс, інакше індекс не буде застосований, і порядок полів має максимально відповідати порядку індексу.
12. Не пишіть деякі беззмістовні запити, наприклад, генеруйте порожну структуру таблиці:
Виберіть COL1,COL2 у #t з T, де 1=0
Цей тип коду не повертає жодного набору результатів, але споживає системні ресурси, тому його слід змінити на щось подібне:
Створити таблицю #t(...)
13. Часто це хороший вибір для заміни на існує:
Виберіть NUM з A Where Num In (Виберіть NUM з B)
Замінимо наступним твердженням:
Виберіть NUM з A, де існує (виберіть 1 з b, де num=a.num)
14. Не всі індекси є дійсними для запитів, SQL базується на даних у таблиці для оптимізації запиту; коли індексний стовпець має велику кількість дублювання даних, SQL-запити можуть не використовувати індекс, наприклад, таблиця має полову стать, чоловічий, жіночий — майже половина, і навіть якщо індекс побудований на статі, він не відіграватиме ролі в ефективності запитів.
15. Чим більше індексів, тим краще, індекс безумовно може підвищити ефективність відповідного вибору, але також знижує ефективність вставки та оновлення, оскільки індекс може бути відновлюватися під час вставки або оновлення, тому побудова індексу потрібно ретельно розглядати залежно від конкретної ситуації. Краще не мати більше 6 індексів у таблиці, а якщо їх занадто багато, розглянуть, чи потрібно будувати індекси на деяких рідко використовуваних стовпцях.
16. Уникайте оновлення кластеризованих індексних стовпців наскільки це можливо, оскільки порядок кластеризованих індексних стовпців відповідає фізичному порядку зберігання таблицьних записів, і після зміни значення стовпця це призведе до коригування порядку всіх записів таблиці, що споживатиме значні ресурси. Якщо вашому додатку потрібно часто оновлювати кластеризовані індексні стовпці, варто подумати, чи варто будувати індекс як кластеризований.
17. Намагайтеся використовувати числові поля і не створювати поля, які містять лише числову інформацію як символи, що знизить продуктивність запитів і з'єднань, а також збільшить витрати на зберігання. Це пов'язано з тим, що рушій порівнює кожен символ рядка по одному під час обробки запитів і об'єднань, тоді як для числових типів його потрібно порівнювати лише один раз.
18. Використовуйте varchar/nvarchar замість char/nchar якомога частіше, бо по-перше, довший простір для зберігання може заощадити місце, а по-друге, для запитів ефективність пошуку в відносно невеликому полі очевидно вища.
19. Не використовуйте select * з t ніде, замініть "*" на конкретний список полів і не повертайте поля, які не використовуються.
20. Спробуйте використовувати змінні таблиці замість тимчасових таблиць. Якщо змінна таблиці містить велику кількість даних, зверніть увагу, що індекс дуже обмежений (лише первинний індекс ключа).
21. Уникайте частого створення та видалення тимчасових таблиць для зменшення споживання ресурсів системної таблиці.
22. Тимчасові таблиці не є непридатними, і їх правильне використання може зробити деякі процедури ефективнішими, наприклад, коли потрібно багаторазово посилатися на набір даних у великій або поширеній таблиці. Однак для одноразових подій найкраще використовувати таблицю експорту.
23. При створенні тимчасової таблиці, якщо обсяг даних, вставлених одночасно, великий, можна використовувати select into замість create table, щоб уникнути збільшення швидкості великої кількості журналів; Якщо обсяг даних невеликий, щоб спростити ресурси системної таблиці, спочатку створіть таблицю, а потім вставте її.
24. Якщо використовується тимчасова таблиця, обов'язково чітко видаляйте всі тимчасові таблиці наприкінці збереженої процедури, спочатку обрізайте таблицю, а потім припиніть таблицю, щоб уникнути тривалого блокування системної таблиці.
25. Намагайтеся уникати використання курсора, оскільки його ефективність низька, якщо обсяг даних перевищує 10 000 рядків, варто розглянути можливість переписування.
26. Слід шукати рішення на основі множин для розв'язання задач перед використанням курсорних або тимчасових таблицевих методів, які часто є ефективнішими.
27. Як і тимчасові таблиці, курсори не є непридатними для використання. Використання FAST_FORWARD курсорів для невеликих наборів даних часто краще, ніж інші методи обробки рядок за рядком, особливо якщо потрібно посилатися на кілька таблиць для отримання потрібних даних. Рутини, які містять «total» у наборі результатів, зазвичай швидші, ніж ті, що виконуються курсором. Якщо є час на розробку, можна спробувати як курсорні, так і множинні методи, щоб визначити, який працює краще.
28. Встановіть SET NOCOUNT ON на початку всіх збережених процедур і тригерів, а SET NOCOUNT OFF — наприкінці. Немає потреби надсилати DONE_IN_PROC повідомлення клієнту після виконання кожного оператора збереженої процедури та тригера.
29. Намагайтеся уникати великих транзакційних операцій і підвищувати сумісність системи.
30. Намагайтеся уникати повернення великих даних клієнту; якщо обсяг даних надто великий, слід оцінити, чи є відповідний попит розумним. |
Опубліковано 27.01.2015 20:09:54
|
|
|
