Порядок полів у складеному порядку індексу з високою селективністю та низькою селективністю

У мене є таблиця SQL Server із понад 3 мільярдами рядків. Один із моїх запитів займає надзвичайно багато часу, тому я розглядаю можливість його оптимізації. Запит виглядає так:

SELECT [Enroll_Date]
      ,Count(*) AS [Record #]
      ,Count(Distinct UserID) AS [User #]
  FROM UserTable
  GROUP BY [Enroll_Date]

[Enroll_Date] - це стовпець із низькою селективністю з менш ніж 50 можливими значеннями, тоді як колонка UserID - це стовпець високої селективності з більш ніж 200 мільйонами різних значень. На основі своїх досліджень я вважаю, що я повинен створити некластеризований композитний індекс на цих двох стовпцях, а теоретично стовпець високої селективності повинен бути першим стовпцем. Але я не впевнений, що в моєму випадку це буде спрацьовувати, оскільки я використовую стовпець із низькою селективністю в групі за пунктом.

У цій таблиці немає кластерного індексу.

Як альтернатива рішенню @ AaronBertrand (якщо ви не можете або не хочете створити індексований вигляд), я рекомендую вам створити індекс на (Enroll_Date, UserID). Якщо такий тип питань є дуже поширеним у вашому столі, це, мабуть, навіть має бути ваш кластерний індекс.

Як правило, я б не рекомендував індекси високої вибірковості як загальної "найкращої практики", а скоріше подивіться, який індекс дасть вашому запиту найкращі показники.

Індекс на (Enroll_Date, UserID)дасть вашому запиту високооптимізований, не блокуючий план запитів із потоковими агрегатами.

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

Відповідь Ааронів - чудове рішення. Я відповім на питання, припускаючи, що ви не хочете використовувати такий підхід.

Запит, який ви опублікували, зазвичай виконуватиметься спочатку групуванням (Enroll_Date, UserID), а потім знову (Enroll_Date). Ця оптимізація є новою для SQL Server 2012. Вона набуває чинності у випадку єдиного COUNT DISTINCT.

Індекс у цих двох стовпцях у певному порядку (Enroll_Date, UserID)буде достатнім для отримання ефективного плану, який поєднує сканування індексу у дві послідовні агрегати потоку. Протилежний порядок не дозволив би зробити цей план.

Тому використовуйте замовлення (Enroll_Date, UserID). Тут у вас немає вибору.

Здається, ідеальний сценарій для індексованого перегляду, який дозволяє платити за розрахунки та агрегати в час запису замість часу запиту.

CREATE VIEW dbo.MyIndexedView
WITH SCHEMABINDING
AS 
  SELECT Enroll_Date, UserID, RawCount = COUNT_BIG(*)
  FROM dbo.UserTable
  GROUP BY Enroll_Date, UserID;
GO

CREATE UNIQUE CLUSTERED INDEX CIX_miv ON dbo.MyIndexedView(Enroll_Date, UserID);

Для створення цього знадобиться деякий час, і, звичайно, знадобиться обслуговування протягом усіх операцій DML, як і індекс базової таблиці.

Тепер запит проти цього представлення був би досить схожим - кожен рядок у представленні тепер представляє собою окреме комбінацію користувача / дати, тому ця цифра може бути обчислена одним COUNT (*), тоді як загальна кількість рядків у базовій таблиці становить вже частково зведені для вас, тепер вам просто потрібно буде додати їх за допомогою SUM на дату:

SELECT Enroll_Date, 
  [Record #] = SUM(RawCount),
  [User #] = COUNT(*)
FROM dbo.MyIndexedView WITH (NOEXPAND)
GROUP BY Enroll_Date; 

Додано підказку NOEXPAND, згадавши це та це .

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

І якщо ви часто використовуєте одні й ті ж загальні пропозиції WHERE щодо Enroll_Date для конкретних, чітко визначених діапазонів (скажімо, поточного кварталу чи року на сьогоднішній день), ви можете додати відповідні відфільтровані індекси, які ще більше зменшують цей ввід / вивід (але завжди є компроміс).

Ви також можете розглянути можливість кластеризованого індексу на базову таблицю. Це, здається, не є одним з тих дуже рідкісних випадків використання, які отримують користь від купи.