Обновить
Теперь это реализовано в SQL Server Azure. Вырабатывает рекомендации
и управление индексами может быть настроено как автоматическое .
Включить автоматическое управление индексами
Вы можете настроить SQL Database Advisor на автоматическую реализацию рекомендаций. По мере появления рекомендаций они будут применяться автоматически. Как и во всех индексных операциях, управляемых службой, если влияние на производительность является отрицательным, рекомендация будет отменена.
Оригинальный ответ
Некоторые базы данных уже (вроде) создают индексы автоматически.
В SQL Server план выполнения может иногда включать в себя оператор Index Spool, где СУБД динамически создает индексированную копию данных. Однако эта катушка не является постоянной частью базы данных, которая синхронизируется с исходными данными, и не может использоваться совместно для выполнения запросов, что означает, что выполнение таких планов может привести к многократному созданию и удалению временных индексов для одних и тех же данных.
Возможно, в будущем СУБД смогут динамически отбрасывать и создавать постоянные индексы в соответствии с рабочей нагрузкой.
Процесс оптимизации индекса, в конце концов, является просто анализом затрат и выгод. Хотя это правда, что люди могут иметь больше информации об относительной важности запросов в рабочей нагрузке, в принципе, нет никаких причин, по которым эта информация не может быть предоставлена оптимизатору. В SQL Server уже есть регулятор ресурсов, который позволяет классифицировать сеансы в разные группы рабочей нагрузки с разным распределением ресурсов в соответствии с приоритетом.
Упомянутые Kenneth отсутствующие индексные DMV не предназначены для слепой реализации, так как они учитывают только преимущества для конкретного запроса и не пытаются учитывать стоимость потенциального индекса для других запросов. Он также не объединяет похожие отсутствующие индексы. например, выходные данные этого DMV могут сообщать об отсутствующих индексах на A,B,CиA,B INCLUDE(C)
Некоторые текущие проблемы с идеей
- Качество любого автоматизированного анализа, который фактически не создает индекс, будет сильно зависеть от точности модели калькуляции.
- Даже в области автоматизированного анализа автономное решение сможет быть более тщательным, чем онлайн-решение, поскольку необходимо, чтобы онлайн-решение не добавляло большие накладные расходы на ведение бухгалтерского учета к работающему серверу и мешало его основной цели выполнения запросов.
- Индексы, создаваемые автоматически в ответ на рабочую нагрузку, будут обязательно создаваться в ответ на запросы, которые сочли бы их полезными, поэтому будут отставать от решений, которые заранее создают индексы.
Вероятно, разумно ожидать, что точность моделей оценки затрат со временем улучшится, но пункт 2 выглядит сложнее для решения, а пункт 3 по своей сути неразрешим.
Тем не менее, вероятно, подавляющее большинство установок не находятся в этой идеализированной ситуации с квалифицированным персоналом, который постоянно отслеживает, диагностирует и предвидит (или, по крайней мере, реагирует на) изменения рабочих нагрузок.
Проект AutoAdmin в Microsoft Research работает с 1996 года.
Цель этого проекта - сделать базы данных самонастраивающимися и самоуправляемыми, используя знания рабочей нагрузки.
На домашней странице проекта перечислены несколько интригующих проектов. Один из них особенно актуален для вопроса здесь
Другая интересная проблема возникает, когда нет доступных администраторов баз данных (например, встроенная база данных или малый бизнес). В таких сценариях может стать важным подход к настройке непрерывного индекса с малым касанием. Мы исследовали решения ... [в] « Онлайн подход к настройке физического дизайна » в ICDE 2007.
Авторы заявляют
Принимая во внимание все более распространенные функции СУБД, такие как онлайн-индексы, привлекательным является поиск более автоматических решений проблемы физического проектирования, которые продвигают современное состояние.
В статье представлен алгоритм
Его основными характеристиками являются:
- По мере оптимизации запросов мы идентифицируем соответствующий набор индексов-кандидатов, который улучшит производительность. Эта функция позволяет продолжать обработку запросов параллельно с индексами, построенными в фоновом режиме.
- Во время выполнения мы отслеживаем потенциальные выгоды, которые мы теряем из-за отсутствия таких индексов-кандидатов, а также полезности существующих индексов при наличии запросов, обновлений и ограничений пространства.
- После того, как мы соберем достаточно «доказательств», что физическое изменение дизайна является полезным, мы автоматически инициируем создание или удаление индекса.
- Онлайн-характер нашей проблемы подразумевает, что мы, как правило, будем отставать от оптимальных решений, которые знают будущее. Тем не менее, тщательно измеряя доказательства, мы гарантируем, что мы не пострадаем от «поздних» решений, что существенно ограничивает размер понесенных убытков.
Реализация алгоритма позволяет регулировать в ответ на изменения нагрузки на сервер, а также может прервать создание индекса, если во время создания рабочая нагрузка изменится и ожидаемое преимущество упадет ниже того уровня, который считается целесообразным.
Заключение авторов по теме Online против традиционного физического тюнинга.
Интерактивные алгоритмы в этой работе полезны, когда администраторы баз данных не уверены в будущем поведении рабочей нагрузки или не имеют возможности проводить всесторонний анализ или моделирование. Если администратор базы данных имеет полную информацию о характеристиках рабочей нагрузки, то лучшим вариантом будет статический анализ и развертывание с помощью существующих инструментов (например, [2, 3]).
Выводы здесь аналогичны тем, которые приведены в другой статье Настройка индексов с помощью автономных запросов
Наш подход не может превзойти помощника по индексам, если вся рабочая нагрузка известна заранее. Однако в динамических средах с развивающимися и меняющимися рабочими нагрузками подход, основанный на запросах, дает лучшие результаты.