Высокоуровневый алгоритм, который MySQL MVCC использует для создания предыдущего снимка - PullRequest
Новая
       26

Высокоуровневый алгоритм, который MySQL MVCC использует для создания предыдущего снимка

0 голосов
/ 28 ноября 2018

Из MySQL руководство о InnoDB Multi-Versioning:

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

Однако я не смог найти никакой информации о том, как именно эти скрытые столбцы (DB_TRX_ID, DB_ROLL_PTR и DB_ROW_ID)используется для создания предыдущего снимка, каков алгоритм?

Другая страница в руководстве о транзакции, доступной только для чтения, гласит следующее:

InnoDB может избежать издержек, связанных с настройкой идентификатора транзакции (поле TRX_ID) для транзакций, которые известны только для чтения.Идентификатор транзакции необходим только для транзакции, которая может выполнять операции записи или блокировать чтение, например SELECT ... FOR UPDATE.Исключение ненужных идентификаторов транзакций уменьшает размер внутренних структур данных, к которым обращаются каждый раз, когда запрос или оператор изменения данных создает представление для чтения.

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

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

1 Ответ

0 голосов
/ 28 ноября 2018

Если есть несколько подключений, изменяющих одну и ту же строку, то для этой строки в «списке истории» есть несколько воплощений этой строки.TRX_ID контролирует видимость: если воплощение старше X, то Соединение может его «увидеть».Иначе, это версия (вспомним V в MVCC), которая еще не видна для этого соединения.(Примечание: уровень transaction_isolation учитывается в «видимости».)

Я подозреваю, что DB_ROLL_PTR (думаю, ROLLBACK) требуется только тогда, когда запрашивается ROLLBACK (или вызовы сбоя).для него).

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

Для получения более подробной информации (и для проверки правильности того, что я сказал), см. блоги JCole .

...