Почему только чтение в индексированной таблице происходит быстрее, а не запись? - PullRequest
0 голосов
/ 23 октября 2018

Структура данных, используемая для индексации в таблице БД, представляет собой B-Tree (по умолчанию, вне B-Tree, R-Tree, Hash).Так как поиск, удаление и вставка могут выполняться в логарифмическом времени в B-дереве, то почему только чтение из индексированной таблицы выполняется быстрее, а запись медленнее?

Ответы [ 3 ]

0 голосов
/ 23 октября 2018

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

Дисковое пространство и штрафы на запись индексов - именно поэтому вам нужно быть осторожным при создании индексов.

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

This:

UPDATE Table SET NonIndexedColumn = 'Value' WHERE IndexedKey = 'KeyValue'

Будет быстрее, чем это:

UPDATE Table SET IndexedColumn = 'Value' WHERE IndexedKey = 'KeyValue'

Но оба приведенных выше, скорее всего, оба будутБыстрее, чем это в любой разумной таблице размеров:

UPDATE Table SET NonIndexedColumn = 'Value' WHERE NonIndexedKey = 'KeyValue'

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

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

0 голосов
/ 26 октября 2018

INSERT и DELETE должны обновлять каждый индекс для таблицы (и кучи, если нет кластеризованного индекса), чтобы поддерживать согласованность.UPDATE s может сойтись с обновлением меньшего количества индексов, в зависимости от того, какие столбцы были затронуты обновлением (поскольку должны обновляться только те индексы, которые индексируют / включают в себя эти столбцы)

A SELECT, onс другой стороны, только чтение, и поэтому, если индекс содержит все столбцы, требуемые SELECT, только , к которому должен быть доступен индекс .Мы знаем, что данные в этом индексе являются точными , точно , потому что операции модификации необходимы для поддержания этой согласованности.

0 голосов
/ 23 октября 2018

Индексы используются только для ускорения SELECT операторов.Для INSERT, UPDATE и DELETE ваши операторы будут работать медленнее, чем обычно, из-за того, что индекс должен быть обновлен как часть оператора.

Я, возможно, должен уточнить UPDATE /DELETE балл.Это правда, что операторы будут замедлены из-за изменения индекса, добавленного к служебной информации, однако начальная часть поиска (WHERE) оператора UPDATE и DELETE может быть ускорена из-за индекса,В основном, в любом месте используется предложение WHERE, и вы ссылаетесь на индексированные поля, часть выбора записи этого оператора должна увидеть некоторое увеличение.

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

...