Чи слід використовувати багато одиничних індексів поля замість конкретних індексів кількох стовпців?

Це питання стосується ефективності методики індексації SQL Server. Я думаю, це відоме як "перетин перетину".

Я працюю з існуючим додатком SQL Server (2008), який має ряд питань щодо продуктивності та стабільності. Розробники зробили деякі дивні речі з індексуванням. Мені не вдалося отримати переконливих орієнтирів з цих питань, а також не можу знайти жодної справді хорошої документації щодо мереж.

На столі є багато стовпців, які можна шукати. Розробники створили єдиний індекс стовпців на EACH пошукових стовпців. Теорія полягала в тому, що SQL Server зможе поєднувати (перетинати) кожен з цих індексів для ефективного доступу до таблиці за більшості обставин. Ось спрощений приклад (у реальній таблиці є більше полів):

CREATE TABLE [dbo].[FatTable](
    [id] [bigint] IDENTITY(1,1) NOT NULL,
    [col1] [nchar](12) NOT NULL,
    [col2] [int] NOT NULL,
    [col3] [varchar](2000) NOT NULL, ...

CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable]  ( [col1] ASC )
CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC )

select * from fattable where col1 = '2004IN' 
select * from fattable where col1 = '2004IN' and col2 = 4

Я думаю, що декілька індексів стовпців, орієнтованих на критерії пошуку, значно кращі, але я можу помилятися. Я бачив плани запитів, які показують, що SQL Server виконує хеш-відповідність на двох пошуках індексу. Можливо, це має сенс, коли ви не знаєте, як шукається таблиця? Спасибі.

Те, що вам потрібно, - це покриття індексів, тобто. індекси, які можуть задовольнити запит самостійно. Але індекс 'покриття' має одну проблему: він охоплює конкретний запит . Отже, щоб розробити хорошу стратегію індексації, ви повинні зрозуміти ваше навантаження: які запити вражають базу даних, які критичні, а які ні, як часто виконується кожен тип запиту і т. Д. І т. Д. І т. Д. І тоді ви збалансуйте це відповідно до вартості запису та оновлення кожного індексу, і там ви маєте свою стратегію індексації. Якщо це звучить складно, це тому, що це складно.

Однак ви можете застосувати деякі правила. MSDN досить добре висвітлює основи:

• Основи дизайну покажчиків
• Загальні рекомендації щодо дизайну покажчиків
• Настанови щодо кластерного індексу
• Некластеризовані рекомендації щодо проектування індексів

Існує також безліч статей, внесених спільнотою, наприклад. Запис на веб-трансляції - DBA Darwin Awards: Index Edition .

І щоб відповісти на ваше запитання конкретно: окремі індекси для кожного стовпця можуть працювати, за умови, що кожен стовпець має високу вибірковість (безліч чітких значень, кожне значення відображається лише кілька разів у базі даних). Отриманий план доступу з використанням хеш-з'єднання між двома скануваннями діапазону індексу зазвичай працює досить добре. Стовпці з низькою селективністю (декілька чітких значень, кожне значення яких багато разів з’являється в базі даних) не мають сенсу самостійно індексуватися, оптимізатор запитів їх просто ігнорує. Однак стовпці з низькою селективністю багато разів роблять хороші складові ключі, коли вони поєднуються з стовпцем із високою селективністю.