Якщо в базі даних є лише одна вставка, чи погано індексувати кожну можливу комбінацію стовпців?

Я працюю над системою звітування, яка потребуватиме великих запитів на вибір, але базується на базі даних, яка заповнюється лише один раз. Системою управління базами даних є Microsoft SQL Server 2017. Напевно, є кращий спосіб розробити подібну систему, але давайте підійдемо до цього теоретично.

Теоретично кажучи:

1. Якщо у нас дуже велика база даних (150М + рядків у кількох таблицях)
2. І ми можемо припустити, що база даних буде заповнена лише один раз.

Чи може індексація кожної можливої ​​комбінації стовпців негативно впливати на вибір запиту?

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

Оскільки ви перебуваєте на SQL Server 2017, завантажуєте один раз і запускаєте звіти, чому б просто не використовувати натомість індекс зберігання кластерних стовпців?

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

Індекси стовпців - Огляд

Якщо у таблиці є N стовпців, кожна можлива комбінація стовпців - 2 ^ N-1 (видалення порожнього набору). Для 10 стовпців, що означають 1023 індекси, для 20 стовпців ми закінчуємо колосальними 1048575 індексами. Більшість індексів ніколи не використовуватимуться, але їх доведеться враховувати оптимізатором. Цілком можливо, що оптимізатор вибере замість кращого неоптимальний індекс. Я б не став на шлях генерації всіляких індексів, замість того, щоб намагатися розібратися, які саме показники були б корисними.

EDIT виправила кількість можливих індексів

Як зазначає Джефф , це навіть гірше, ніж 2 ^ N (встановлення потужності), оскільки (3,2,1) явно відрізняється, ніж (1,2,3). Для N стовпців ми можемо вибрати першу позицію в індексі, що містить усі стовпці N способами. Для другої позиції способами N-1 і т. Д. Ми, таким чином, закінчуємо N! різні індекси повного розміру. Жоден з цих індексів не включає інший індекс у цьому наборі. Крім того, ми не можемо додати ще один коротший індекс, щоб він не охоплювався жодним повним індексом. Отже, кількість індексів становить N !. Приклад для 10 стовпців, отже, стає 10! = 3628800 індексів і для 20 (барабанний) 2432902008176640000 індексів. Це насмішкувато велика кількість, якщо ми помістимо крапку для кожного показника по одному мм частину, пройде світловий промінь 94 дні, щоб пропустити всі крапки. Все і все, не ;-)

Ні.

Індексувати "все" не представляється практичним, але можна проіндексувати "більшість".

Ось річ. Якщо в таблиці є Nстовпці, то кількість можливих індексів становить N!. Скажімо, у таблиці є 10 стовпців, тоді у вас немає лише 10можливих індексів, але 10!. Тобто ... 3628 800 ... на одному столі. Це багато місця на диску, вводу / виводу диска, кешу та часів пошуку.

Чому? Кілька причин:

• Індекси Lightwwight зазвичай кешовані, що робить їх легкими швидко. Якщо у вас є 3 мільйони з них, вони НЕ збираються кешувати.

• Оптимізатор SQL може зайняти багато часу, вирішивши, який з них краще використовувати, особливо при використанні приєднань.

• Оптимізатор SQL може відмовитися від використання всеосяжного алгоритму та спробувати евристичний алгоритм. Це може бути "менш оптимальним". Наприклад, PostgreSQL має різні варіанти "запитів таблиці менше 8" та "табличних запитів більше 8".

• Покажчики повинні бути легшими за купу. Якщо ви індексуєте все, то індекс стає таким же важким, як і купа ... щось, що перемагає призначення індексу.

Ні, це, ймовірно, не матиме негативного впливу на SELECTзапити, але

• Це призведе до високого використання диска.
• Це значно збільшить INSERTвитрати.
• Більшість ваших індексів ніколи не використовуються.
• У багатьох WHEREвиразах умов все ще не використовуються індекси, в основному більш складні.
• Кількість необхідних індексів збільшиться в експоненціальному відношенні до числа стовпців. Тобто якщо у вас, наприклад, 8 стовпців, вам потрібно 256 індексів для всіх можливих комбінацій.