Почему базы данных не создают свои собственные индексы автоматически?

Я бы подумал, что базы данных будут достаточно знать о том, с чем они часто сталкиваются, и смогут ответить на требования, предъявляемые к ним, что они могут решить добавить индексы к крайне запрашиваемым данным.

Обновить

Теперь это реализовано в 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]).

Выводы здесь аналогичны тем, которые приведены в другой статье Настройка индексов с помощью автономных запросов

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

Созданный вами индексный дизайн - это скорее искусство, чем наука. СУБД недостаточно умна, чтобы выдерживать обычные рабочие нагрузки и разрабатывать умную стратегию индексирования. Это зависит от вмешательства человека (читай: DBA) для анализа рабочей нагрузки и определения наилучшего подхода.

Если бы не было штрафов за наличие индексов, тогда было бы подходом дробовика просто добавить бесконечное количество индексов. Но поскольку изменение данных (INSERTS, UPDATES и DELETES) влияет на включенные индексы в таблице, то эти переменные будут иметь дополнительную служебную нагрузку для этих переменных.

Требуется человеческий дизайн и стратегия для умного создания индексов, которые максимизируют производительность чтения при минимальных затратах на изменение данных.

На самом деле, есть несколько баз данных, которые делают это. Например, Google BigTable и Amazon SimpleDB автоматически создают индексы (хотя ни одна из них не является СУБД) . Есть также по крайней мере один движок СУБД MySQL, который делает это. SQL Server также отслеживает индексы, которые, по его мнению, вы должны создать , хотя на самом деле это не так далеко, как их создание.

Проблема на удивление трудно исправить, поэтому неудивительно, что большинство баз данных не создают их автоматически (BigTable / SimpleDB обходится без него, потому что они не допускают произвольных объединений, что значительно упрощает задачу) . Кроме того, создание индексов на лету - это трудоемкий процесс, который требует эксклюзивного доступа ко всей таблице - определенно не то, что вам нужно, когда таблица находится в режиме онлайн.

Однако, учитывая количество веб - приложений ламповый там были написаны любителями , которые даже не знают , что индекс является , я все еще думаю , что эта функция будет полезна для некоторых людей.

Хотя уже есть несколько обширных ответов, они, похоже, обходят реальный ответ: индексы не всегда желательны.

С аналогией с автомобилями, упомянутой в комментариях, было бы лучше сказать, почему не все автомобили оснащены пакетами для экстремальных видов спорта? Частично это расходы, но это также связано с тем, что многим людям не нужны или нужны низкопрофильные шины и жесткая подвеска; это излишне неудобно.

Поэтому, возможно, у вас есть 1000 операций чтения для каждой вставки, почему бы не создать автоматически созданный индекс? Если таблица широкая и запросы разнообразны, почему бы не иметь несколько? Может быть, фиксация важна по времени, а чтение - нет; в данных обстоятельствах может быть недопустимо замедлять вставку. Может быть, вы работаете с ограниченным дисковым пространством, и вы не можете позволить себе иметь дополнительные индексы, поглощающие пространство, которое у вас есть.

Дело в том, что индексы не создаются автоматически, потому что они не являются ответом на все вопросы. Разработка индексов - это не просто случай сказать: «Эй, это ускорит мои чтения», есть и другие факторы, которые следует учитывать.

Они могут анализировать прошлые запросы и предлагать / создавать индексы, однако это не работает оптимально, потому что индексы находят баланс, чтобы ускорить то, что вы хотите оптимизировать по стоимости, и сервер не может знать ваши намерения.

Они не умные, они кусок кода. Каждый раз, когда вы вводите новые данные в базу данных, ей нужно найти новое местоположение и карту, чтобы найти ее, когда она запрашивается. Индексирование звучит проще, чем просто, вы просто даете новый номер новому фрагменту данных? Хорошо, а как насчет того, чтобы следующий запрос был не о последнем фрагменте данных, а о 36271 фрагментах ранее? Вы можете легко найти его по индексу, верно? Но что, если запрос включает в себя слово типа «рыбалка», которое можно найти в старом фрагменте 36271, сделанном в 1997 году? Ho? Ни слова о рыбалке в старой статье.

Если данные поступают в базу данных один за другим, они могут быть проиндексированы таким образом. Но простая индексация рано или поздно приведет к неверным результатам и / или снижению производительности ...