Вставки занимают больше времени при увеличении количества строк в таблице?Зачем? - PullRequest
Новая
       9

Вставки занимают больше времени при увеличении количества строк в таблице?Зачем?

0 голосов
/ 21 февраля 2019

Если у меня есть таблица с первичным ключом, то есть физически упорядоченный кластерный индекс, который имеет тип integer и имеет значение идентификации, например, так (псевдо-SQL-код): 

MyTable
--------
Id ( int, primary key, identity(1, 1) )
MyField1
MyField2

  1. Будет ли операция вставки в эту таблицу занимать больше времени по мере роста числа строк в таблице?Почему?

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

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

  2. И будет ли это иметь какое-либо значение для времени дифференциальной вставкиесли таблица не имеет индекса?То есть, если первичный ключ в вышеуказанном случае отсутствовал?

Где можно прочитать о том, как реляционная база данных хранит таблицу в ОЗУ и на диске?

1 Ответ

0 голосов
/ 21 февраля 2019

Обычно накладные расходы на вставку строки состоят из нескольких компонентов.Я могу подумать:

  1. Поиск страницы для размещения строки.
  2. Обновление индексов.
  3. Регистрация транзакции.
  4. Любые накладные расходы на триггеры и ограничения.

Для (1).Из-за кластеризованного индекса в столбце идентификаторов новая строка попадает в таблицу в «конце» таблицы, то есть на последней странице.В данном случае нет связи между размером таблицы и местом для поиска строки.

Для (2).Существует очень небольшая дополнительная нагрузка на обновление кластеризованного индекса по мере роста таблицы.Но это очень мало - и фрагментация, кажется, не проблема.

For (3).Это не связано с размером таблицы.

Для (4).Похоже, у вас нет триггеров или ограничений, так что это не проблема.

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

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

...