Индекс на высокой таблице записи это плохо? - PullRequest
Новая
       16

Индекс на высокой таблице записи это плохо?

2 голосов
/ 08 июля 2011

Я получил книгу Oracle 9i от издателя Oracle.
В нем написано

Index is bad on a table which is updated/inserted new rows frequently

Это правда? или речь идет только об Oracle [а не о других пакетах RDBMS]?

Edit

У меня в MySQL есть такая таблица

  • ID [pk / AI]
  • Пользователь [целое число]
  • Текст [TinyText]
  • Время [Отметка времени]

В эту таблицу допускается только запись / чтение.
Когда PK создает Index, нарушается ли дизайн таблицы?
Если да, как решить проблему такого типа [где AI является первичным ключом]

Ответы [ 3 ]

4 голосов
/ 08 июля 2011

Это верно для любой базы данных в определенной степени. При каждом обновлении индексированных столбцов индекс также должен обновляться. Каждый дополнительный индекс добавляет дополнительные издержки. То, имеет ли это значение для вашей конкретной ситуации, зависит от индексов, которые вы создаете, и рабочей нагрузки, на которой работает сервер. Последствия для производительности лучше всего обнаружить с помощью бенчмаркинга.

2 голосов
/ 08 июля 2011

Это не значит, что индексы в таблицах с высокой изменчивостью являются «плохими». Просто это влияет на производительность операций DML. Я думаю, что автор пытался сказать, что вы должны тщательно рассмотреть необходимость индексов для таких активных таблиц.

Как и во всех вычислениях, речь идет о компромиссах. По сути, @Michael утверждает, что «это зависит». Вы также можете иметь высокую частоту запросов к таблице, при которой индексы в таблице избегают большого количества полных сканирований таблицы. В таком случае ваши накладные расходы на обслуживание индекса вполне могут стоить выгоды, получаемой от индексов запросов.

Кроме того, я бы в любом случае не купил бы книгу 9i, если бы это не было реальной сделкой. Я бы порекомендовал вам прочитать что-нибудь от Тома Кайта, особенно «Экспертная архитектура баз данных Oracle» или «Эффективный Oracle по замыслу».

2 голосов
/ 08 июля 2011

Индексы предназначены только для извлечения данных.Поскольку они являются указателем на расположение данных, операторы INSERT / UPDATE / DELETE медленнее поддерживают индексы.Даже в этом случае индексы могут быть фрагментированы, потому что удаление / обновление изменится - вот почему существуют инструменты для поддержки этого и статистики таблиц (оба используются оптимизатором для определения плана EXPLAIN).

Имейте в видучто индексы не являются ANSI - это чудо, синтаксис и терминология так похожи.Но функциональность практически идентична между базами данных, которые ее предоставляют.Например, у Oracle есть только «индексы», в то время как MySQL и SQL Server различают кластеризованные (по одному на таблицу) и некластеризованные индексы.

Для обращения к обновлению о первичном ключе.Первичный ключ является уникальным и считается неизменным (хотя он и может быть изменен, хотя значение должно быть уникальным для столбца).Удаление из таблицы приведет к фрагментации индекса, который требует мониторинга с помощью специальных инструментов поставщика базы данных, если производительность становится проблемой.

...