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

13

Наприклад, якщо у мене є два індекси:

CREATE INDEX IDX_1 ON MY_TABLE_1
 (ITEM, DATE, LOCATION)
 COMPUTE STATISTICS;

CREATE INDEX IDX_2 ON MY_TABLE_1
 (DATE, LOCATION, ITEM)
 COMPUTE STATISTICS;

Це зробило б IDX_2зайвим? Якщо ні, то як визначити порядок декларування стовпців?

Чи слід підбирати індекси до звичайних запитів?

oracle index

— Льюїс Нортон
джерело

12

Так, користь приходить, коли ви хочете запитувати частину індексу. Якщо ви поставите спочатку використані предикати предикати, індекс можна використовувати для запитів, які включають ці предикати, але не для всіх стовпців індексу.

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

У вашому випадку IDX_2це не обов'язково зайве, залежно від характеру запитів у таблиці. Однак, можливо, не потрібно буде включати всі стовпці. Якщо, наприклад, ви робите багато запитів locationі dateтоді, IDX_2можливо, буде корисно вирішити ці запити, оскільки IDX_1це не в правильному порядку, щоб бути корисним для цього. Однак, можливо, ви вважаєте itemце зайвим IDX_2.

Починаючи з 9i, Oracle представив оператор "пропустити сканування" , за допомогою якого ефективніші запити стовпчиків індексів можна запитувати, що може зменшити потребу в додаткових індексах такого роду.

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

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

— Занепокоєний щодоTunbridgeWells
джерело

3

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

— Адам Муш

2

Інша річ, яку слід врахувати - це стовпці з великою кількістю нульових значень.

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

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

— Міхал Тененберг
джерело