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

Внутренние Детали Мультиуправления версиями

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

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

Сегменты отката и Параллельные Пределы Транзакции

В MySQL 5.5 предел на параллельных изменяющих данные транзакциях был значительно увеличен, удаляя узкое место, которое следовало из единственного сегмента отката InnoDB, который поддерживал максимум 1023 параллельных изменяющих данные транзакций. Единственный сегмент отката был разделен на 128 сегментов, каждый поддерживающий до 1023 транзакций, создавая новый предел приблизительно 128 k параллельных транзакций.

В MySQL 5.7.2 128 K предела транзакции уменьшается до 96 K, чтобы поддерживать введение нового типа журнала отмены для нормальных и сжатых временных таблиц и связанных объектов. 32 из 128 сегментов отката теперь резервируются для транзакций временной таблицы.

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

Это изменение листы 96 сегментов, каждый поддерживающий до 1023 транзакций, для предела 96 K параллельных изменяющих данные транзакций. 96 K предела предполагает, что транзакции не изменяют временные таблицы. Если бы все изменяющие данные транзакции также изменяют временные таблицы, пределом составил бы 32 K параллельных транзакций.

Направляющие линии для Управления Сегментами Отката

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

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

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

Если Вы вставляете и удаляете строки в небольших пакетах на приблизительно том же самом уровне в таблице, поток чистки может начать отставать, и таблица может стать больше и больше из-за всех "мертвых" строк, делая все ограниченное диском и очень медленное. В таком случае отрегулируйте новые операции строки, и выделите больше ресурсов потоку чистки, настраиваясь innodb_max_purge_lag системная переменная. См. Раздел 14.2.6,"InnoDB Опции запуска и Системные Переменные" для получения дополнительной информации.