14.3 InnoDB Multi-Versioning — MySQL 5.7

14.3 InnoDB Многоверсионность

InnoDB — это многоверсионный хранилище данных. Оно хранит информацию об старых версиях изменённых строк, чтобы поддерживать такие транзакционные функции, как одновременная работа и откат. Эта информация хранится в системном табличном пространстве или в пространстве таблиц отката в структуре данных, называемой сегментом отката. См. Раздел 14.6.3.4, «Undo Tablespaces». InnoDB использует информацию в сегменте отката для выполнения операций отката, необходимых в откате транзакции. Она также использует информацию для построения предыдущих версий строки для согласованного чтения. См. Раздел 14.7.2.3, «Согласованное чтение без блокировок».

Внутренне, InnoDB добавляет три поля к каждой строке, хранящейся в базе данных:

Поле DB_TRX_ID размером 6 байт указывает идентификатор транзакции для последней транзакции, которая вставила или обновила строку. Также удаление обрабатывается как обновление, где специальный бит в строке устанавливается для обозначения удаления.
Поле DB_ROLL_PTR размером 7 байт, называемое указателем отката. Указатель отката указывает на запись журнала отката, записанную в сегмент отката. Если строка была обновлена, запись журнала отката содержит информацию, необходимую для восстановления содержимого строки до её обновления.
Поле DB_ROW_ID размером 6 байт содержит идентификатор строки, который монотонно увеличивается при вставке новых строк. Если InnoDB генерирует кластеризованный индекс автоматически, индекс содержит значения идентификаторов строк. В противном случае столбец DB_ROW_ID не отображается ни в одном индексе.

Журналы отката в сегменте отката делятся на журналы отката вставки и обновления. Журналы отката вставки необходимы только при откате транзакции и могут быть удалены как только транзакция подтверждается. Журналы отката обновления используются также при согласованном чтении, но могут быть удалены только после того, как не будет транзакции, для которой InnoDB назначил снимок, который в согласованном чтении мог потребовать информации в журнале отката обновления для построения более ранней версии строки базы данных. Для дополнительной информации о журналах отката см. Раздел 14.6.7, «Журналы отката».

Рекомендуется регулярно подтверждать транзакции, включая транзакции, которые выполняют только согласованное чтение. В противном случае, InnoDB не может удалить данные из журналов отката обновления, и сегмент отката может стать слишком большим, заполнив табличное пространство, в котором он находится. Для получения информации о управлении пространствами таблиц отката см. Раздел 14.6.3.4, «Undo Tablespaces».

Физический размер записи журнала отката в сегменте отката обычно меньше соответствующей вставленной или обновлённой строки. Вы можете использовать эту информацию для расчёта требуемого пространства для вашего сегмента отката.

В схеме многоверсионности InnoDB строка не удаляется физически из базы данных сразу же, когда вы удаляете её с помощью SQL-запроса. InnoDB только физически удаляет соответствующую строку и её записи индекса, когда удаляет запись журнала отката обновления, написанную для удаления. Эта операция удаления называется очисткой, и она довольно быстрая, обычно занимает столько же времени, сколько и SQL-запрос, который произвёл удаление.

Если вы вставляете и удаляете строки небольшими партиями примерно с одинаковой скоростью в таблице, поток очистки может начать отставать, и таблица может увеличиваться из-за всех «мёртвых» строк, что делает всё зависящим от диска и очень медленным. В таких случаях ограничьте новые операции со строками и выделите больше ресурсов потоку очистки, настроив системную переменную innodb_max_purge_lag. Для получения дополнительной информации см. Раздел 14.8.10, «Настройка очистки».

Многоверсионность и вторичные индексы

InnoDB многоверсионный механизм управления одновременным доступом (MVCC) обращается со вторичными индексами по-другому, чем с кластеризованными индексами. Записи в кластеризованном индексе обновляются на месте, и их скрытые системные столбцы указывают на записи журналов отката, из которых можно восстановить предыдущие версии записей. В отличие от записей кластеризованного индекса, записи вторичных индексов не содержат скрытых системных столбцов и не обновляются на месте.

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

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

Однако, если оптимизация «Оптимизация передачи условия индекса» (ICP) включена и части условия WHERE можно оценить, используя только поля из индекса, сервер MySQL всё равно передает эту часть условия WHERE в движок хранения данных, где она оценивается с использованием индекса. Если не найдено совпадений, поиск в кластеризованном индексе не выполняется. Если совпадения найдены, даже среди записей, помеченных как удалённые, InnoDB ищет запись в кластеризованном индексе.