SQL є описовий, декларативний мову. Це означає, що запити SQL як би задають питання, a SQL Server самостійно вирішує, як на них відповісти. Виходячи з цього, левова частка оптимізації виконується на рівні SQL Server, а не самих запитів.
Розглядаючи приблизну вартість кожної логічної операції на основі розподілу даних, доступних індексів і можливостей обладнання, оптимізатор запитів (Query Optimizer) будує дерево логічних операцій, що забезпечують якнайшвидше виконання поставленого завдання, тобто загальний план виконання запиту.
Таким чином, оптимізація запитів здебільшого є питанням створення правильних індексів, таких, щоб оптимізатор запитів зміг відібрати дані найбільш швидким способом. Тільки у виняткових випадках зміна структури запиту може вплинути на продуктивність. У той же час більшість виробничих запитів, написаних трьома різними способами, повернуть ідентичні (а то і повністю збігаються) плани виконання.
Налаштування індексів є навиком, що вимагає глибокого розуміння декількох незалежних факторів. Насправді настройку запитів ускладнює те, що сам оптимізатор запитів є чимось на зразок чорного ящика. І перед тим як ви зможете передбачити його поведінку, ви повинні зрозуміти взаємозв'язок наступних факторів.
? Сторінкова архітектура SQL Server, модель фізичної схеми і логічні оператори плану виконання запиту.
? Розподіл даних, статистика індексів, вибір індексів оптимізатором запитів і забезпечення обслуговування індексів.
? Групові структура індексів, коефіцієнт заповнення, злиття сторінок і обслуговування індексів.
? Запити, індекси, плани виконання запитів і оптимізатор запитів.
? Повторне використання плану запиту і застосування параметрів.
Як розробник або адміністратор баз даних ви повинні розуміти, які індекси є кращими серед маси виробничих запитів, а не тільки одного запиту.
Найкраще, що я можу порекомендувати, - це вивчити всі фактори, а потім провести власні експерименти, щоб зрозуміти всі складнощі кореляції між даними, схемою, індексами і запитами. Коригування індексів не робить ніякого впливу на логічний результат будь-якого запиту. Адміністраторам баз даних не слід боятися експериментувати з індексами.
Індексація
Покажчик книги допомагає читачам швидко знайти відповідь на їх питання. Кращим предметний покажчик вважається той, який відкриває читачеві найкоротший шлях від постановки їм питання до знаходження відповідного тексту в книзі. Індекси бази даних грають таку ж роль.
Незважаючи на те що індекси можуть бути складними, мета індексації проста: скорочення числа популярних фізичних сторінок.
основи індексації
Існують два основних типи індексів. Покажчик, який фізично сортує текстові сторінки, подібно телефонній книзі, називається кластерізованний, так як самі дані збудовані в специфічному порядку. Цей тип предметного покажчика фізично знаходиться в тексті книги. Природно, текст може бути відсортований в даному випадку тільки в одному порядку. Аналогічно, таблиці SQL Server можуть мати тільки один фізичний порядок сортування, і саме він називається кластерізованний індексом таблиці.
Некластерізованний індекс подібний предметному покажчику в кінці книги - він відправляє читача на певні сторінки. Будь-яке питання може бути без праці знайдений в тексті, якщо спочатку знайти його в предметному покажчику, а потім відправитися за посиланням на конкретну сторінку. SQL Server також має в своєму розпорядженні некластерізованний індексами, які виконують сортування, використовуючи стовпці, відмінні від кластерізованного індексу.
Стовпці, які використовуються в індексах, називають ключовими.
Так як первинні ключі реалізують унікальний метод ідентифікації будь-якого рядка, індекси і первинні ключі взаємопов'язані - первинний ключ повинен бути індексований, але в той же час він може бути кластерізованний або некластерізованний.
При плануванні індексів існує деяка напруга у відносинах між обслуговуванням запитів відбору і запитів поновлення. Незважаючи на те що індекси підвищують продуктивність запитів, за це доводиться розплачуватися додатковими витратами на оновлення індексів при вставці і оновленні рядків. Однак деякі індекси необхідні при операціях запису. Операції оновлення та видалення перед здійсненням фізичного запису повинні відібрати рядки, а хороші індекси можуть прискорити цей відбір, одночасно підвищуючи ефективність самого запису.
Додаткова Індекси таблиць не можна плутати з індексованими уявленнями. Редак- інформація ція Enterprise Edition містить функцію денормалізації, яка будує кластерізованний індекс, що поширюється на безліч таблиць. Неправильне використання індексованих уявлень може істотно знизити продуктивність операційних баз даних. У розділі 53 ми більш детально поговоримо про індексованих уявленнях.
Групові індекси
Кластерізованний індекс являє собою інструмент злиття збалансованого дерева зі сторінками даних таблиць, що підтримує дані в тому ж фізичному порядку, що і індекс (рис. 50.1), Листові вузли збалансованого дерева індексу фактично є даними сторінок даних.
Мал. 50.1. Кластерізованний індекс пов'язує листові вузли сторінок індексів зі сторінками даних, забезпечуючи той же порядок даних, що і в індексі
Кластерізованний індекс може вплинути на продуктивність одним з описаних нижче способів.
? Коли операція пошуку знаходить рядок, використовуючи кластерізованний індекс, потрібні дані знаходяться саме в ній. Це робить стовпець, який використовується для ідентифікації рядків, можливим кандидатом для первинного ключа і ідеальним - для кластерізованного індексу.
? Групові індекси групують рядки з однаковими або подібними значеннями в найменшу можливу кількість сторінок, скорочуючи тим самим кількість рядків даних, необхідних для отримання набору рядків. Таким чином, Групові індекси ідеально підходять для стовпців, які найбільш часто використовують для відбору діапазонів рядків (як приклад можна привести стовпець OrderDetail. OrderlD).
/ Будь-яка таблиця має деякий фізичний порядок. Якщо таблиця не має
На замітку кластерізованного індексу, то вона знаходиться у вигляді купи, тобто в неврегульованих вигляді. В цьому випадку рядки, при неможливості ідентифікації по ключового стовпця кластерізованного індексу, ідентифікуються за допомогою внутрішнього ідентифікатора рядка (RowiD) купи. Цей ідентифікатор не використовується в запитах.
некластерізованний індекси
Некластерізованний називається індекс у вигляді збалансованого дерева, що починається з кореневого вузла і зростаючого через проміжні вузли до листовим вузлів. Листові вузли вказують безпосередньо на рядки сторінок даних (див. Рис. 50.1). Таблиця SQL Server 2005 може мати до 249 ^ кластеризованих індексів, але мені на практиці не зустрічалися таблиці, що вимагають більше десяти добре продуманих індексів.
Некластерізованний індекс може бути створений за обчислюваному колонки. Для включення можливості створення індексу або індексованого подання по обчислюваному колонки слід встановити для параметра quoted_identif ier значення on.
створення індексів
У вікні Object Explorer утиліти Management Studio існуючі індекси кожної таблиці перераховані під вузлом Databases ^ Tables ^ Indexes. Властивості кожного нового або існуючого індексу можна коригувати в діалоговому вікні Index Properties (рис. 50.2). Це вікно відкривається для існуючого індексу клацанням правої кнопки миші на його імені і вибором в контекстному меню пункту Properties. Нові індекси створюються за допомогою контекстного меню вузла Indexes конкретної таблиці.
В утиліті Management Studio індекси відображаються як вузли на панелі Object Explorer. За допомогою вибору в контекстному меню вузла Indexes пункту New Index можна створити новий індекс. У відкривається при цьому формі містяться чотири вкладки.
? General. Містить ім'я індексу, його тип, властивість унікальності, а також ключові стовпці.
? Options. Управляє режимом роботи індексу. Тут же будь-який індекс може бути відключений і знову включений.
? Included Columns. Містить неключових стовпці, службовці оболонкою індексу.
? Storage. Дозволяє помістити індекс в обрану файлову групу.
Puc. 50.2. Параметри будь-якого індексу можна встановити в діалоговому вікні Index Properties утиліти Management Studio
При відкритті вікна параметрів існуючого індексу воно містить також і дві додаткові вкладки.
? Fragmentation. Відображає детальну інформацію про стан індексу.
? Extended Properties. Містить додаткові параметри, визначені користувачем.
Зміни, які вносять у вікні параметрів індексу, можна застосувати негайно за допомогою клацання на кнопці Про До; їх застосування можна відкласти на заданий час, а також втілити всі зміни в сценарій. Для цього можна скористатися значками у верхній частині вікна.
У програмному коді індекси створюються за допомогою інструкції CREATE INDEX. У наступному прикладі створюється кластерізованний індекс IxOrderld, заснований на зовнішньому ключі OrderlD таблиці OrderDetail:
CREATE CLUSTERED INDEX IxOrderlD ON dbo.OrderDetail (OrderlD);
I Для отримання вичерпної інформації про індекси за допомогою про-
S VS граммного коду використовують такі функції та подання каталогів:
I * sysindexes, sysindex_columns, sysstats, sysstats_columns, sysdm_db_
* Index_physical_stats, sysdm_index_operational_stats, sysindexkey_
property і sysindex_col.
Кластерізованний індекс створюється автоматично при визначенні первинного ключа. Для видалення індексу використовується інструкція DROP INDEX, в якій вказується ім'я таблиці та ім'я індексу, наприклад:
DROP INDEX OrderDetail.IxOrderlD
Дополнітешрая Створені індекси не підтримують ефективне стан автоматично, інформація Операції поновлення можуть фрагментировать індекси і змінювати коеффіці- ент заповнення їх сторінок. У цьому розділі ми лише згадуємо про необхідність обслуговування індексів, тогдп як в главі 37 розповідалося про вимоги, необхідних для забезпечення продуктивності індексів.
складові індекси
Складовим називають кластерізованний або некластерізованний індекс, що включає безліч стовпців. На практиці більшість індексів є складовими. Якщо ви використовуєте вікно параметрів індексу утиліти Management Studio, то складені індекси створюються за допомогою додавання безлічі стовпців у вкладці General. Для створення складеного індексу в програмному коді він повинен бути оголошений за допомогою інструкції DDL CREATE INDEX після створення таблиці. У наступному прикладі створюється складовою кластерізованний індекс для таблиці GUIDE бази даних СНА2:
CREATE CLUSTERED INDEX IxGuideName ON dbo.Guide (LastName, FirstName);
Порядок стовпців в складеному індексі дуже важливий. Щоб при пошуку отримати всі переваги складеного індексу, останній повинен містити найбільш часто використовувані стовпці в напрямку зліва направо. Якщо складовою індекс виглядає як lastname, firstname, то пошук тільки по firstname не використовуватиме індекс, а пошук по lastname або спільно з lastname і firstname - буде.
Додаткова SQL Server 2005 може індексувати слова в стовпчиках за допомогою функції інформація повнотекстового пошуку, яку ми обговорювали в главі 13.
первинні ключі
Первинний ключ може бути спочатку визначений як кластерізованний або некластерізованний індекс. Однак, щоб змінити тип індексу, обмеження первинного ключа повинно бути видалено або знову створено. Це досить важке завдання, якщо присутня безліч зовнішніх ключів або якщо таблиця реплицируется.
Додаткова Про створення первинних ключів см. В главі 17.
інформація
покривають індекси
Покриває називають будь-який індекс, який повністю задовольняє потребам конкретного запиту SELECT. Так як СУБД SQL Server сама вибирає, який індекс використовувати для пошуку даних, існує ймовірність, що в некластерізованний індексі запитом знадобляться всі стовпці. В даному випадку реляционное ядро буде витягувати дані з індексних сторінок і ніколи не буде здійснювати читання зі сторінок даних. Це істотно скорочує операції введення-виведення, так як читання здійснюється з більш вузьких таблиць, що містять на одній сторінці більше даних, а додаткове читання зі сторінок даних взагалі не виконується.
При проектуванні покриває індексу дуже важливо усвідомлювати, як кластерізованний індекс впливає на некластерізованний. Оскільки некластерізованний індекс повинен мати здатність звертатися до сторінок даних, на своїх листових вузлах він повинен містити ключовий стовпець кластерізованного індексу (якщо в таблиці такий існує). При цьому стовпці кластерізованного індексу включаються в кінець кожного некластерізованно- го індексу (навіть якщо ви їх не бачите явно в діалоговому вікні властивостей індексу). Наприклад, якщо деяка таблиця має кластерізованний індекс по стовпцю ContactID і некластерізованний за стовпцями LastName і FirstName, то некластерізованний індекс містить дані зі стовпців LastName, FirstName (відсортовані), а також ContactID (невідсортовані). Знання цього факту дуже важливо при проектуванні покривають індексів.
Покриває індекс може мати необхідність включати деякі стовпці, які не вимагають реляционное ядро для ідентифікації рядків, відсіяних пропозицією WHERE. Ці додаткові, неключових стовпці не відчувають потребу в сортуванні в збалансованому дереві індексу - вони включаються виключно з метою повернення стовпців запитом SELECT.
Недоліком покривають індексів в попередніх версіях SQL Server було Новинка 4 те, що при оновленнях повинні були сортуватися всі стовпці - навіть ті, 2005 які не використовувалися при відборі рядків, а були включені виключно
для повернення даних. Здатність версії SQL Server 2005 відокремлювати неключових стовпці підвищила продуктивність операцій оновлення з використанням покривають індексів, в яких не сортуються неключових стовпці. При цьому за рахунок зменшення розміру збалансованого дерева індексу покращилася продуктивність вилучення даних запитом.
Для визначення неключових стовпців в некластерізованних індексах використовується параметр INCLUDE. Ці неключових стовпці не сортуються як частина структури збалансованого дерева індексу і включаються тільки в його листові вузли. У наступному прикладі створюється індекс, сортують дані за стовпцем OrderNumber і включає дані з шпальти OrderDate:
CREATE NONCLUSTERED INDEX IxOrderNumber ON dbo. [Order] (OrderNumber)
INCLUDE (OrderDate);
Завдяки включаються стовпцями як вузької копії широкої таблиці, які SQL Server постійно синхронізує з вихідною таблицею, для отримання даних не потрібно читання додаткових сторінок.
Включаються стовпці не враховано в обмеженнях некластерізованний індексу- 16 ключових стовпців і 900 байтів. Насправді в покриває індекс можна включити до 1023 неключових стовпців. Як включаються можуть бути також і стовпці з особливо великими типами даних - XML, varchar (max), nvarchar (max) і varbinary (max), - навіть незважаючи на те, що вони не можуть виступати в ролі ключових стовпців.
Стовпець таблиці можна розділити, якщо він бере участь у ролі включається стовпчика в покриває індексі. Перед тим як розділити такий стовпець, слід видалити покриває індекс.
Місцезнаходження файлової групи
Якщо база даних використовує безліч іменованих файлових груп, то індекс може бути створений в певній з них. Для цього у визначенні індексу використовується параметр
ON імя_файловой_группьг.
CREATE NONCLUSTERED INDEX імя_індекса ON Table (стовпці)
ON імя_файловой_группи;
Цей параметр може виявитися корисним для розподілу потоків введення-виведення в особливо сильно завантажених базах даних. Наприклад, якщо Web-сайт запитується мільйонному користувачів в хвилину, його головна сторінка використовує запит, що включає дві таблиці і три індексу, і при цьому є кілька дискових підсистем, то приміщення кожної таблиці і її індексів у власну дискову підсистему значно підвищить продуктивність. Слід зауважити, що кластерізованний індекс повинен знаходитися в одній дискової підсистеми зі пов'язаної з ним таблицею, так як їх сторінки об'єднані.
Додаткова Фізичне розміщення таблиць і індексів може бути налаштоване і інформація більш глибоко, з використанням файлових груп і розділів. Більш докладно _ ці теми ми обговоримо в главі 53.
параметри індексів
Індекси SQL Server 2005 мають кілька параметрів, в тому числі унікальність, виділення простору, а також параметри продуктивності.
унікальні індекси
Параметр UNIQUE INDEX є чимось більшим, ніж просто індексом з обмеженням на унікальність, - унікальним індексам доступна оптимізація. Первинний ключ або обмеження на унікальність автоматично створюють унікальний індекс.
У Management Studio унікальний індекс створюється за допомогою установки прапорця Unique у вкладці General діалогового вікна параметрів індексу.
У програмному коді унікальність індексу вказується за допомогою додавання в визначення ключового слова UNIQUE:
CREATE UNIQUE INDEX OrderNumber ON [Order] (OrderNumber);
Коефіцієнт заповнення індексу
Будь-якому індексу потрібно трохи вільного простору в дереві, щоб вставка нових записів не приводила до реструктуризації індексу. Коли сервера потрібно вставити новий запис в заповнену сторінку, він розбиває цю сторінку на дві, після чого записує дві наполовину повні сторінки на диск. Такий хід речей викликає три потенційні проблеми: розбивається сама сторінка, нові сторінки більше не є послідовними, і на кожній сторінці міститься менший обсяг інформації. В результаті для читання того ж обсягу даних буде потрібно переглянути більшу кількість сторінок.
Оскільки індекс являє собою збалансоване дерево, кожна сторінка повинна містити як мінімум два рядки. Коефіцієнт заповнення і параметр pad index впливають як на проміжні сторінки, так і на листові вузли, як показано в табл. 50.1.
Таблиця 50.1. Коефіцієнт заповнення і параметр pad index
коефіцієнт
Заповнення
проміжні сторінки
Листовий вузол
0
Одна вільна запис
100% -ве заповнення
1-99
Одна вільна запис або обсяг, менший коефіцієнта заповнення, якщо встановлено параметр pad index
Обсяг, менший коефіцієнта заповнення
100
Одна вільна запис
100% -ве заповнення
Коефіцієнт заповнення застосовується тільки до листовим вузлів індексу, якщо до нього не застосовано параметр pad index. Цей параметр вказує сервера застосовувати слабкість коефіцієнта заповнення також і до проміжних рівнях збалансованого дерева.
Найкращий коефіцієнт заповнення залежить від призначення бази даних і типу кластерізованного індексу. Якщо база даних призначена в першу чергу для отримання даних або первинний ключ є послідовним, то високий коефіцієнт заповнення дозволить максимально упакувати індексні сторінки. Якщо кластерізований індекс непослідовно (наприклад, природний первинний ключ), то таблиця потенційно сприйнятлива до поділу сторінок, - в цьому випадку використовуйте низький коефіцієнт заповнення і часто виконуйте дефрагментацію сторінок.
Додаткова Коефіцієнт заповнення індексу в міру поділу сторінок поступово ут ікформація рачівает свою роль. Для відновлення коефіцієнта заповнення план обслуговування повинен включати в себе періодичну реіндексацію. Інформація про порядок підтримки індексів міститься в главі 37.
У Management Studio коефіцієнт заповнення встановлюється у вкладці Options діалогового вікна параметрів індексу. У програмному коді Т-SQL параметри коефіцієнта заповнення і index pad вказуються після команди CREATE INDEX. У наступному прикладі створюється індекс OrderNumber з 15% вільного простору як на листових вузлах, так і на проміжних сторінках:
CREATE NONCLUSTERED INDEX IxOrderNumber ON dbo. [Order] (OrderNumber)
WITH FILLFACTOR = 85, PAD_INDEX = ON;
Управління блокуванням індексів, їх створення в реальному часі і ограни- Норінко чення паралелізму індексів є новими параметрами, що з'явилися
2005 у версій SQL Server 2005. Для параметрів pad_index, fillfactor, sort_in_db,
ignore_dup_key, statistiсs_norecompute і drop_existing був змінений синтаксис. Новий синтаксис вимагає обов'язкового включення вирази = оп. З міркувань забезпечення сумісності продовжує підтримуватися і старий синтаксис, проте в майбутніх версіях цього вже не буде.
Обмеження блокувань і паралелізму
Режим роботи блокувань в запитах, які використовують індекси, може управлятися за допомогою параметрів allow_row_locks і allow_page_locks. Зазвичай ці блокування дозволені.
Порядок сортування індексів
СУБД SQL Server здатна створювати спадні індекси. Будь-який запит, який використовує пропозицію ORDER BY, призведе до сортування по зростанню, якщо в цьому пропозиції не буде явно вказано ключове слово DESC.
В інструкції DDL CREATE INDEX ключові слова AS С і DESC йдуть безпосередньо за ім'ям стовпця.
Параметр ігнорування дублюються ключів
Параметр I GNORE_DUP_KEY не впливає на сам індекс, а тільки на те, як згодом індекс буде впливати на зміни даних.
Зазвичай транзакції є атомарними. Це означає, що транзакція або виконується, або ні, як логічна одиниця. У той же час параметр ігнорування дублюються ключів направляє транзакції вставки на підтвердження операції для всіх рядків, що задовольняють умові унікальності індексу, і ігнорування всіх рядків, що порушують вимогу унікальності індексу.
Цей параметр не порушує унікальність індексу. Два записи залишаються в таблиці, таким чином, цілісність бази даних залишається незайманою, в той час як атомарность транзакцій порушується. Незважаючи на те що цей параметр значно полегшує імпорт трильйонів сумнівних рядків, мені не подобаються ніякі параметри, що ослабляють характеристики Асю (тобто атомарности, цілісності, ізольованості і живучості) бази даних.
У наступному прикладі повторюється попередня інструкція створення унікального індексу, але в ній використаний параметр ігнорування дублюються ключів:
CREATE UNIQUE INDEX OrderNumber ON [Order] (OrderNumber)
WITH IGNORE_DUP_KEY = ON
Параметр видалення існуючого індексу
Параметр DROP_EXISTING вказує сервера видалити поточний індекс і відтворити його з нуля. Це може привести до деякого виграшу в порівнянні з перебудовою існуючого індексу в разі, якщо він є кластерізованний, а таблиця містить також і некластерізованний індекси. Це пов'язано з тим, що перебудова кластерізованного індексу призводить до автоматичної перебудови всіх некластерізованних індексів.
Параметр заборони перерахунку статистики індексу
Оптимізатор запитів SQL Server залежить від статистики розподілу даних в питанні визначення, який з індексів є більш істотним в конкретному критерії пошуку в таблиці. Зазвичай SQL Server оновлює цю статистику автоматично. У той же час безпосередньо перед запитом деякі таблиці можуть отримати великий обсяг даних, і в цьому випадку статистика може виявитися застарілою. Спеціально для ситуацій, в яких статистика потребує оновлення вручну, призначений параметр statistics_norecompute, який скасовує автоматичне оновлення статистики. Практично для всіх індексів цей режим роботи не рекомендується.
Сортування в базі tempdb
Параметр sort_in_tempdb = on змінює метод створення індексу, форсуючи використання бази tempdb, а не пам'яті. Якщо індекс постійно віддаляється і відтворюється, то цей параметр здатний скоротити час створення індексу. У більшості індексів цей параметр не має великого значення, до того ж він не обов'язковий.
відключення індексу
Будь-індекс може бути тимчасово відключений. Для цього досить зняти прапорець Use Index у вкладці Option діалогового вікна параметрів індексу. У програмному коді T-SQL цей ефект досягається за допомогою включення параметра DISABLE в інструкцію DDL ALTER INDEX:
ALTER INDEX [IxContact] ON [dbo]. [Contact] DISABLE
У деяких особливо інтенсивних операціях імпорту виявляється швидше видалити індекс і відтворити його, ніж оновлювати його при вставці кожного рядка. Перевага відключення індексу полягає в тому, що метадані індексу обслуговуються в самій базі даних, а не залежать від програмного коду, що відтворює коректний індекс.
Відключення кластерізованного індексу фактично призводить до відключення Увага! всій таблиці.
Щоб знову включити індекс, використовується команда ALTER INDEX. . . REBUILD WITH:
ALTER INDEX [PK____ Contact 0BC6C43E]
ON [dbo]. [Contact]
REBUILD WITH (PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF,
ALLOW ROW LOCKS = ON,
ALLOW_PAGE_LOCKS = ON,
SORT_IN_TEMPDB = OFF,
ONLINE = OFF)
Створення базових індексів
Навіть перед налаштуванням місцезнаходження кількох індексів легко визначити. Ці базові індекси є першим кроком у створенні цілісного набору індексів. Нижче наведено кілька рекомендацій, якими варто скористатися перед створенням цих базових індексів.
1. Створіть кластерізованний індекс для кожної з таблиць. У первинних таблицях такий індекс краще організувати на шпальтах, найбільш ймовірно використовуються для визначення того рядків, - відмінним кандидатом є первинний ключ. У вторинних таблицях, в яких найчастіше вилучають безліч пов'язаних рядків, створюйте кластерізованний ключ для найбільш важливого зовнішнього ключа, групують разом ці пов'язані стовпці.
2. Створіть некластерізованний індекси для стовпців кожного зовнішнього ключа, за винятком тих, які були проіндексовані в п. 1. Як ключі індексу використовуйте тільки значення зовнішнього ключа.
3. Створіть одностолбцовий індекс для всіх стовпців, які найбільш ймовірно будуть з'являтися в пропозиціях WHERE, ORDER BY або GROUP BY.
У той час як запропонований план індексації далекий від досконалості, він пропонує початковий компроміс між відсутністю індексів і налаштованими індексами. В принципі його можна розглядати як базовий рівень продуктивності по відношенню до подальшої налаштування індексів.
Джерело: Нільсен, Пол. Microsoft SQL Server 2005. Біблія користувача. : Пер. з англ. - М .: ТОВ "І.Д. Вільямс", 2008. - +1232 с. : Іл. - Парал. тит. англ.
