Оновлення
Це зараз реалізовано в SQL Server Azure. Це формує рекомендації
та управління індексами може бути налаштовано як автоматичне .
Увімкнути автоматичне управління індексом
Ви можете встановити Радник баз даних SQL автоматично реалізовувати рекомендації. Як тільки рекомендації стануть доступними, вони будуть автоматично застосовані. Як і у всіх операціях з індексом, якими керує служба, якщо вплив на продуктивність негативний, рекомендація буде скасована.
Оригінальний відповідь
У деяких базах даних вже (вид) індекси створюються автоматично.
У SQL Server план виконання іноді може включати в себе оператор Index Spool, де RDBMS динамічно створює індексовану копію даних. Однак ця котушка не є стійкою частиною бази даних, яка зберігається синхронізовано з вихідними даними, і її неможливо розділити між виконанням запитів, тобто виконання таких планів може закінчитися неодноразовим створенням та видаленням тимчасових індексів на ті самі дані.
Можливо, в майбутньому RDBMS матимуть здатність динамічно падати та створювати стійкі індекси відповідно до завантаженості.
Процес оптимізації індексу зрештою є лише аналізом витрат та вигод. Хоча це правда, що люди можуть мати більше інформації про відносну важливість запитів у робочому навантаженні в принципі, але немає причин, чому ця інформація не могла б бути доступною для оптимізатора. У SQL Server вже є регулятор ресурсів, який дозволяє класифікувати сеанси в різні групи навантаження з різним розподілом ресурсів відповідно до пріоритету.
Відсутній показник DMV, згаданий Кеннетом, не планується реалізовувати наосліп, оскільки вони враховують лише переваги конкретного запиту та не намагаються врахувати вартість потенційного індексу для інших запитів. Він також не консолідує аналогічні відсутні індекси. наприклад, вихід цього DMV може повідомити про відсутніх індексах на A,B,CіA,B INCLUDE(C)
Деякі актуальні проблеми з ідеєю є
- Якість будь-якого автоматизованого аналізу, який фактично не створює індекс, буде сильно залежати від точності моделі калькулювання.
- Навіть в області автоматизованого аналізу офлайн-рішення зможе бути більш ретельним, ніж рішення в Інтернеті, оскільки вкрай важливо, щоб онлайн-рішення не додавало великі накладні книги на живий сервер і не заважало його основній меті виконувати запити.
- Індекси, створені автоматично у відповідь на навантаження, обов’язково будуть створені у відповідь на запити, які вважали б їх корисними, тому відставатимуть від рішень, які створюють індекси заздалегідь.
Мабуть, розумно очікувати, що точність моделей витрат з часом поліпшиться, але точка 2 виглядає складніше для вирішення, а точка 3 по суті нерозв'язна.
Тим не менш, напевно, переважна більшість установ не перебувають у цій ідеалізованій ситуації з кваліфікованими кадрами, які постійно контролюють, діагностують та передбачають (або принаймні реагують на) зміни навантаження.
Проект AutoAdmin в Microsoft Research працює з 1996 року
Мета цього проекту - зробити бази даних самонастроєними та самоуправляючими, використовуючи знання робочого навантаження
На домашній сторінці проекту перелічено декілька інтригуючих проектів. Одне особливо актуальне для цього питання
Ще одна цікава проблема виникає, коли немає доступних баз даних (наприклад, вбудована база даних або малий бізнес). У таких сценаріях може стати важливим підхід безперервної настройки індексу з низьким дотиком. Ми дослідили рішення ... [in] " Інтернет-підхід до настройки фізичного дизайну " в ICDE 2007.
Автори констатують
З дедалі більш поширеними функціями СУБД, такими як індекси в Інтернеті, привабливим є вивчення більш автоматичних рішень проблеми фізичного дизайну, які сприяють розвитку сучасного рівня.
У статті представлений алгоритм
Основними його характеристиками є:
- По мірі оптимізації запитів ми визначаємо відповідний набір кандидатських індексів, які б підвищили ефективність. Ця функція дозволяє обробці запитів тривати паралельно з індексами, які будуються у фоновому режимі.
- Під час виконання ми відстежуємо потенційні вигоди, які ми втрачаємо, не маючи таких кандидатських індексів, а також корисність існуючих індексів за наявності запитів, оновлень та обмежень місця.
- Після того, як ми наберемо достатньо «доказів», що фізична зміна дизайну є корисною, ми автоматично запускаємо створення індексів чи їх видалення.
- Принцип нашої проблеми в Інтернеті означає, що ми загалом будемо відставати від оптимальних рішень, які знають майбутнє. Однак, ретельно вимірюючи докази, ми гарантуємо, що ми не зазнаємо серйозних "пізніх" рішень, тим самим обмежуючи суму понесених збитків
Реалізація алгоритму дозволяє здійснювати заглушку у відповідь на зміни завантаження сервера, а також може припинити створення індексу, якщо під час створення зміни робочого навантаження та очікувана користь опускаються нижче того, що вважається доцільним.
Висновок авторів на тему " Інтернет проти традиційної фізичної настройки".
Онлайн-алгоритми в цій роботі корисні, коли DBA не впевнені в майбутньому поведінці робочого навантаження або не мають можливості робити всебічний аналіз чи моделювання. Якщо DBA має повну інформацію про характеристики робочого навантаження, то статичний аналіз та розгортання за допомогою існуючих інструментів (наприклад, [2, 3]) буде кращою альтернативою.
Висновки тут схожі з висновками в іншому документі " Налаштування індексів, керований автономними запитами"
Наш підхід не може обіграти радника з індексів, якщо все навантаження відомо заздалегідь. Однак у динамічних середовищах, що змінюються та змінюються навантаженнями, підхід, орієнтований на запити, дає кращі результати.