Чи є перевага в тому, щоб не вирівняти розділ індексом?

9

Я маю честь керувати великою розділеною таблицею OLAP. Переглядаючи цю таблицю, я помітив, що один із показників не узгоджується зі схемою розподілу. Оскільки автор не доступний і ретельно продумані пошукові запити Google не повернули корисних результатів, я не впевнений, чи це було навмисно чи випадково.

Чи є якась причина, щоб розділ не вирівняв індекс на SQL Server 2008?

— Робін
джерело

1

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

— Алі Разегі

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

— Робін

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

— Дан Гузман

11

Основна перевага НЕ розбиття (не рідкість) індексу на Секціонірованние базовий об'єкті є те , що вона працює навколо давнього обмеження оптимізатора запитів , пов'язане з впорядкованими запитами даних , такі як MIN, MAXабо TOP (n)запити.

На Секціонірованние індексу, оптимізатор взагалі не може перевести MIN, MAXабо TOP (n)в одній і тій же операції за перегородкою , з подальшою кінцевої глобальної сукупності більш часткових агрегатів за перегородкою. Натомість оптимізатор вибирає план виконання, який сканує всі розділи індексу. Виняток з цього становить єдиний випадок, коли сукупність або верхня операція задається над стовпчиком розподілу.

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

Стаття Іціка Бен-Гана, що пояснює проблему.

— Пол Білий 9
джерело

3

Існує очевидна проблема навколо деяких обмежень (наприклад, унікальних), що вимагають нерівневого індексу.

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

— Ремус Русану
джерело

1

Так. Вибір позаблокового індексу повинен бути дуже усвідомленим вибором. Я робив це сам (рідко) в минулому, але в дуже конкретних обставинах, коли користь перевищувала витрати.

— Пол Білий 9

2

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

Неспрямовані індекси корисні, оскільки ви можете застосувати до них унікальні обмеження для всієї таблиці. Крім того, для нерівневих індексів не потрібно, щоб ключ розбиття був неявним префіксом пошуку. Уявіть, що 10000 розділів та запитів не базуються на ключі розбиття. План виконання повинен буде шукати 10000 розділів, якщо індекс був вирівняний. Інші відповіді мають додаткові приклади.

— usr
джерело