Де слід помістити індекси в таблицю часових вимірів?

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

Що робити, якщо використовується таблиця часових розмірів, нижчий рівень деталізації якої є добовим. Куди слід поставити індекси?

Ренді Мелдер у запитанні: Що означає "індекс" на RDBMS? сказав:

Подумайте про індекс як "зміст" ... це впорядкований список покажчиків на позиції у файлі, так само зрушення

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

Моє запитання: чи варто ставити індекси для всіх цих полів?

День, мабуть, унікальний, тому для цього я чудово розумію використання індексів. Але тиждень ідентифікатор матиме 7 випадків , місяць - 30/31 випадків , для чверті - більше 120 випадків .

• Чи варто все-таки ставити індекси для цих полів?
• Чи все-таки це стане в нагоді?

Я прошу вас, тому що в тому ж питанні Девід Спіллет сказав:

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

То які найкращі міркування для випадку часового виміру?

Ви, ймовірно, не зіткнетеся з проблемами запису, оскільки я припускаю, що це було б щось створене один раз (або один раз на рік), а потім не торкалося б.

Але використання індексу, ймовірно, буде перешкодою, якщо ви шукаєте по тижнях ... Проблема полягає в тому, що якщо індекс використовується, він може сканувати це спочатку, а потім захопити кожен запис із таблиці окремо, що коли ви ' повторно витягуючи понад 5-20% записів, зазвичай швидше зробити повне сканування таблиці, а потім скинути записи, які вас не цікавлять.

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

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

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

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

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

Поки моїм основним правилом було взагалі не вводити жодних індексів у мої бази даних про розробку, поки я працюю над ними. Коли виробнича база даних збільшується, я використовую журнал баз даних і EXPLAINз'ясовую, що потребує індексації, а потім створюю лише необхідні індекси. Це працює добре, поки використання бази даних поступово збільшується, а кількість індексів залишається низькою.

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