Індекс ( англ. index ) - об'єкт бази даних, який створений з метою підвищення ефективності виконання запитів. Таблиці в базі даних можуть мати велику кількість рядків, які зберігаються в довільному порядку, і їх пошук по заданому значенню шляхом послідовного перегляду таблиці рядок за рядком може займати багато часу. Індекс формується із значень одного або декількох стовпців таблиці і покажчиків на відповідні рядки таблиці і, таким чином, дозволяє знаходити потрібну рядок по заданому значенню. Прискорення роботи з використанням індексів досягається в першу чергу за рахунок того, що індекс має структуру, оптимізована для пошуку - наприклад, збалансованого дерева. Деякі СУБД розширюють можливості індексів введенням можливості створення індексів по ним. Наприклад, індекс може бути створений за висловом upper (last_name) і відповідно буде зберігати посилання, ключем яких будуть значення поля last_name у верхньому регістрі. Крім цього, індекси можуть бути оголошенні як унікальні так і не унікальні. Унікальний індекс реалізує обмеження цілісності на таблиці, виключаючи можливість вставки значень, які повторюються.
Архітектура
Існує два типи індексів: кластерні і некластерный. У кожній таблиці може бути тільки один кластерний індекс і багато некластерные. При присутності кластерного індексу рядка таблиці фізично зберігаються в заданому порядку і безпосередньо пов'язані з елементами індексу, завдяки чому значно прискорюється доступ до даних при виконанні запитів, які використовують цей індекс. Якщо в таблиці немає кластерного індексу, таблиця є невпорядкованою. Некластерный індекс, створений для такої таблиці, що містить лише вказівник на запису таблиці, у зв'язку з чим за вибіркою необхідно принаймні ще одне звернення до диска для отримання саме запису таблиці.
Індекси фізично можуть бути реалізовані різними структурами. Найбільш часто B + дерева і хеш-таблиці.
Послідовність стовпчиків у складеному індексі
Послідовність, в якій представлені стовпці в складеному індексі, досить важлива. Справа в тому, що отримати набір даних по запросу, зачіпає лише перший з проіндексованих стовпчиків, можна. Однак у більшості СУБД неможливо або неефективно отримання даних тільки за другий і т.д. проиндексированным стовпцях (без обмежень на перший).
Наприклад, уявімо собі телефонний довідник, розсортованих спочатку по місту, потім по прізвища, і потім по імені. Якщо ви знаєте місто, тоді ви легко можете знайти всі телефони цього міста. Однак у такому довіднику буде складно знайти всі телефони, записані на певний прізвище - для цього необхідно подивитися в секцію кожного міста та пошукати там потрібну інформацію. Деякі СУБД виконують цю роботу, інші ж просто не використовують такий індекс.
Ефективність
Для оптимальної ефективності запитів індекси зазвичай створюються на тих стовпці таблиці, які часто використовуються в запитах. Для однієї таблиці можуть бути створені кілька індексів. Однак збільшення числа індексів уповільнює операції додавання, оновлення та видалення рядків таблиці, оскільки при цьому необхідно оновлювати самі індекси. Крім цього індекси займають додатковий об'єм пам'яті, тому перед створенням індексу потрібно впевнитися, що виграш, який планується в ефективності запитів переважить додаткові витрати ресурсів комп'ютера на супровід індексу.
Обмеження
Індекси корисні для багатьох програм, проте на їх використання накладаються обмеження. Візьмемо такий запит SQL : SELECT first_name FROM people WHERE last_name = 'Франкенштейн';. Для виконання такого запиту без індексу СУБД повинна перевірити поле last_name в кожному рядку таблиці (цей механізм відомий як «повний перебір» або «повний скан таблиці», в плані може відображатися словом «NATURAL»). При використанні індексу СУБД просто проходить по бінарному дереву, поки не знайде запис «Франкенштейн».такою прохід вимагає набагато менше ресурсів, ніж повний перебір таблиці.
Тепер візьмемо такий запит: SELECT email_address FROM customers WHERE email_address LIKE '% @ yahoo.com';. Цей запит повинен нам знайти всіх клієнтів, у яких е-мейл закінчується на "@ yahoo.com», однак навіть якщо колонку email_address є індекс, СУБД все одно буде використовувати повний перебір таблиці. Це пов'язано з тим, що індекси будуються в припущенні, що слова / символи йдуть зліва направо. Використання символу підстановки на початку умови пошуку виключає для СУБД можливість використання пошуку по бінарному дереву. Ця проблема може бути вирішена створенням додаткового індексу за висловом reverse (email_address) і формуванням запиту виду: select email_address from customers where reverse (email_address) like reverse ('% @ yahoo.com');. У цьому випадку символ підставновки опиниться в найбільш правою позиції («moc.oohay%»), що не виключає використання індексу за reverse (email_address).
