Нужно ли рассматривать удаление существующего индекса, потому что это префикс рекомендуемого индекса? - PullRequest
7 голосов
/ 16 августа 2011

Советник по настройке SQL в Oracle SQL Developer v3 предлагает для моего запроса следующее:

Рекомендуется запустить Access Advisor для улучшения структуры физической схемы или создания рекомендованного индекса. Если вы решите создать рекомендуемый индекс, рассмотрите возможность его удаления" SCHEMANAME ". " INDEXNAME " (на "COLUMN1") , поскольку этопрефикс рекомендуемого индекса.

create index SCHEMANAME.NEW_INDEXNAME on SCHEMANAME.TABLENAME("COLUMN1","COLUMN2");

Есть ли какой-либо вред в , а не , делающем предложение жирным шрифтом?Проблема в том, что существующий индекс, который он предлагает отбросить, используется другими процедурами.Я не думал, что idex могут «навредить» друг другу, есть ли минус в том, чтобы оставить оба индекса отдельно от места на диске, которое они занимают, и незначительное снижение производительности при вставке / обновлении?

Ответы [ 3 ]

9 голосов
/ 16 августа 2011

Итак, если OLD INDEX включен [Column1], а RECOMMENDED INDEX включен [Column1] [Column2], рекомендуемый индекс можно использовать и для существующих запросов.

Вкратце: удаление СТАРЫЙ ИНДЕКС, как вы сказали, увеличит производительность при вставке / обновлении , а также не уменьшит возможность поиска перепросмотр запросов, которые использовали OLD INDEX.РЕКОМЕНДУЕМЫЙ ИНДЕКС По-прежнему допускает поиск значений [Column1], а также значений [Column1] [Column2].

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

7 голосов
/ 16 августа 2011

На самом деле может произойти снижение производительности при удалении индекса для одного столбца.

Предположим, вы выполняете запрос с WHERE [Column1] = 123.Это можно решить с помощью оригинального индекса.Новый индекс также может быть использован для этого, но в зависимости от реализации потребуется также прочитать значения для [Column2] в индексе, даже если они не используются.

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

[Обновление 9 сентября.]
Недавно я столкнулся с другой ситуацией, когда отдельный индекс может быть намного лучше , чем комбинированный индекс..
Рассмотрим огромную таблицу «ошибок» со столбцами [status], [creatate] и некоторыми другими полями.Большинство ошибок будут закрыты, поэтому предположим, что статус равен «0» (открыт) для 100 записей и «1» (закрыт) для 99000 записей.

SELECT * FROM bugs WHERE status = '0' значительно выиграет от индекса на status, тогда как приSELECT * FROM bugs WHERE status = '1' индекс для status не поможет.

Oracle будет знать разницу, поскольку он строит статистику по индексу.

Однако с объединенным индексом по status, createdate каждый индексзапись почти уникальна, и Oracle решит не использовать индекс для запроса SELECT * FROM bugs WHERE status = '0', потому что он догадывается (ошибочно), что индекс не поможет.

Таким образом, в этой ситуации не следует отбрасывать только один индекспотому что это префикс к комбинированному индексу.

Примечание: Теоретически Oracle может построить еще более умную статистику по индексу, но, похоже, этого не происходит.

5 голосов
/ 16 августа 2011

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

Недостатком их оставления является снижение производительности операций CRUD на вашей таблице.Из вашего поста следует понимать, что в данный момент это может быть «незначительным», но таблицы со временем растут, и в будущем это может привести к проблемам, которые затем необходимо будет устранить.

Это также излишне потребует больше памяти.

Ваши предыдущие процедуры также смогут использовать новый индекс.

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

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

Удалите его, протестируйте свои «другие» процедуры »производительность, и вы должны увидеть небольшую разницу, если есть проблема, вы можете инвестироватьigate почему и при необходимости замените его.

...