Количество слов в статье: 5889 слов. Чтение занимает около 20 минут.

краткое содержание

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

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

Введение в MVCC

MVCC, полное название Multi-Version Concurrency Control, то есть многоверсионный контроль параллелизма.

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

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

Проблемы управления параллелизмом

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

Преимущества MVCC

Механизм MVCC имеет следующие преимущества:

• Улучшайте производительность одновременно: операции чтения не будут блокировать операции записи.,Операции записи не будут блокировать операции чтения.,иметические производительные кузизодновременные программы.
• Снижен риск взаимоблокировок: поскольку для одновременного управления не требуются явные блокировки.,MVCC может снизить риск тупиковой ситуации.

Текущее чтение и чтение снимка

Прежде чем объяснять принцип MVCC,Давайте сначала поймем,Текущее чтение и чтение снимка。

сейчас читаю

В MySQL сейчас Чтение — это метод операции чтения данных. Он может напрямую читать последнюю изданную версию. При чтении он также должен гарантировать, что другие одновременно дела не смогут изменить текущую запись, и прочитанная запись будет заблокирована. MySQL сейчас предоставляет две реализации чтениеиз Механизм:

• Последовательное чтение(Последовательное Read）：
  • При уровне изоляции по умолчанию (повторяемое чтение) MySQL использует согласованное чтение для достижения текущего уровня. читаю。
  • В начале дел,MySQL создаст согласованное представление (согласованное представление).,Этот вид отражает начало работы временной библиотеки из снимка.
  • Во время выполнения дел,Независимо от того, какие изменения в данные внесли другие дела.,дела всегда использует единообразное представление для чтения данных.
  • Это гарантирует, что результаты, возвращаемые несколькими запросами в рамках одного запроса, согласованы.,Таким образом достигнув сейчас читаю.
• Блокировка Read）：
  • Заблокированное чтение — особый случай метод чтения, используемый в определенных сценариях.
  • При использовании заблокированного чтения,MySQL получит общую блокировку или исключительную блокировку перед выполнением операции чтения.,Чтобы обеспечить согласованность данных.
  • Общий замок Lock) позволяет нескольким делам одновременно читать одни и те же данные, а эксклюзивная блокировка (Exclusive Блокировка) не позволяет другим делам читать или записывать данные.
  • Заблокированное чтение подходит для сценариев, где требуется строгий контроль доступа.,Однако из-за больших затрат производительности, вызванных блокировкой,Рекомендуется использовать его только при необходимости.

Ниже перечислены все эти грамматики, которые сейчас читаю:

Сейчас читаю на самом деле операция блокировки, которая представляет собой пессимистическую реализацию блокировки.

чтение снимка

чтение снимка — это единообразный вид при чтении данных, MySQL использует MVCC Механизм поддержки чтения снимка。

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

При выполнении операции запроса MySQL определяет видимую версию данных на основе согласованного представления транзакции. Видны только те версии данных, которые были зафиксированы до начала транзакции. Незафиксированные данные или данные, измененные после начала транзакции, не видны для текущей транзакции.

вроде разблокировано select Операция чтения снимка, то есть неблокирующее и неблокирующее чтение.

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

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

MVCC в основном реализует конфликты чтения и записи без блокировки.,И это чтение означает чтение снимка, является реализацией оптимистической блокировки.

Анализ принципов MVCC

Неявные поля

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

Undo Log

Журнал отмены был упомянут выше. Этот журнал отмены является ядром MVCC.

Журнал отмены (Undo Log) — это важный журнал транзакций в MySQL. Роль журнала отмены в основном имеет два аспекта:

• откат транзакции：когдадела Когда необходим откат,MySQL может применитьUndo бревновую старуюценить, восстановить данные до состояния, существовавшего до начала дел.,Гарантированная откат транзакций.
• Реализация MVCC：MVCC даInnoDBдвигатель храненияиз Одна из основных особенностей。проходитьиспользоватьUndoбревно,MySQL может предоставлять независимые представления изображений для каждого дела.,Это позволяет делам видеть версию, которая является согласованной и соответствует требованиям уровня изоляции и зданных при чтении данных.

В механизме хранения InnoDB журналы отмены делятся на два типа: вставка (вставка) журнала отмены и обновление (обновление) журнала отмены.

• insert undo log：вставлятьUndoбревнода Укажите навставлятьгенерируется во время работыизUndoбревно。потому чтовставлятьдействоватьиз Записыватьтолько правильнокогдавпередделавидимый,Невидимый для других дел,Поэтому его можно удалить сразу после отправки дела.,Операция продувки не требуется.
• update undo log: Update Undobrevno означает создание изUndobrevno во время операции обновления или удаления. Обновление отмены бревно может потребовать предоставления механизма MVCC, поэтому они не могут быть удалены немедленно при отправке дел. Вместо этого они будут помещены в связанный список отмены бревно при отправке и будут ждать, пока поток очистки выполнит окончательную операцию удаления. просто установить старый рекорд DELETED_BIT фактически не удаляет устаревшие записи. Чтобы сэкономить дисковое пространство, InnoDB специализируется на потоках очистки для их очистки. DELETED_BIT для trueizrecord.

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

Изменения одной и той же строки записи различными транзакциями или одной и той же транзакцией приведут к тому, что журнал отмены строки записи станет связанным списком. Голова цепочки — это самая последняя запись, а хвост цепочки — самая старая старая запись.

Например, если транзакция А вставляет новую запись: вставьте в значения пользователя (идентификатор, имя) (1, «Сяо Мин»)

Теперь пришла транзакция B и изменила имя записи на «Сяо Ван».

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

После завершения копирования измените имя строки на «Сяо Ван, и измените скрытый ПолеизделаID для текущей Транзакции». БизID, и скопируйте указатель отката в undo log Запись копирования означает, что это моя последняя версия. После фиксации транзакции блокировка снимается.

В это время приходит другая транзакция C, чтобы изменить ту же запись и изменить имя на «Сяохун».

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

Что касается взаимодействия между DB_ROLL_PTR и журналом отмены, конкретный процесс выглядит следующим образом:

1. перед операцией обновления или удаления,MySQL запишет старую цену в Undobrevno.
2. когдадела Когда необходим откат,MySQL будет соответствии сделаиз Отменить Бревно Запись,проходить DB_ROLL_PTR оказатьсяпереписыватьсяизUndoбревно。
3. в соответствии сUndoбревносередина Записыватьизстарыйценить,MySQL восстанавливает старую цену в соответствующую изданную строку.,Реализуйте операцию отката данных.

Например, если вы хотите вернуться к транзакции B и значением имени является «Xiao Wang», вам нужно всего лишь использовать DB_ROLL_PTR, чтобы найти соответствующий журнал отмены в списке и восстановить старое значение в строке данных.

Благодаря сотрудничеству DB_ROLL_PTR и журнала отмены MySQL может эффективно управлять согласованностью и изоляцией транзакций. Использование журналов отмены также позволяет MySQL поддерживать MVCC, тем самым обеспечивая согласованность чтения и изоляцию транзакций в средах с высоким уровнем параллелизма.

цепочка версий

В MVCC,Для каждой операции обновления,Старая цена будет сохранена в папке отмены.,Даже если это старая версия этой записи. По мере увеличения количества обновлений,Все версии иметьиз ​​будут иметь атрибутroll_pointer, подключенный в связанный список.,позвони этодляцепочка версий。

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

Read View

Просмотр согласованности, полное имя Read View , используется для оценки цепочки версийв Какая версия правильная?когдавпередделадавидимыйиз

Read View Грубо говоря, дела осуществляет чтение снимка генерирует режим чтения (Read Просмотр), в котором читается исполнение дел снимкаизтот момент,Будет создан снимок текущей системы библиотеки данных.,Записывать и поддерживать текущий активный идентификатор делаиз системы (при включении каждого дела),будет присвоен идентификатор,Этот идентификатор увеличивается из).

здесьиметь Немного Уведомлениеодин раз：Read Просмотр только для RC и уровень RR

Read Uncommitted（RU）и Сериализуемые — это два специальных уровня изоляции, которые не нужно использовать. Read View Основные причины:

• Read Нефиксированный (RU) уровень изоляции: на RU На уровне изоляции дела могут читать другие дела, которые еще не отправлены, и зданные, то есть грязное чтение. Это означает, что нет необходимости в проведении Read View Чтобы ограничить объем доступа, дела могут свободно читать другие дела из незафиксированных данных. Поскольку видимость строго не контролируется, нет необходимости создавать или использовать Read View。
• Сериализуемый уровень изоляции: at Serializable В рамках уровня изоляции дела имеют самый высокий уровень изоляции, гарантируя, что при каждом чтении будет виден согласованный снимок. Чтобы достичь этого уровня изоляции, MySQL использует механизм блокировки, гарантирующий последовательное выполнение между транзакциями. Поскольку дела выполняются последовательно и не допускают одновременных операций, нет необходимости использовать Read View Делайте выводы о видимости.

Read Uncommitted и Serializable Правила транзакций на уровне изоляции не предполагают Read View оценка видимости. РУ Допускаются грязные чтения, в то время как Serializable Механизм блокировки используется для обеспечения последовательного выполнения. Следовательно, при этих двух уровнях изоляции нет необходимости создавать или использовать Read View。

Прочтите принципы видимости представления

Просмотр чтения следует принципу видимости: извлекается DB_TRX_ID данных, подлежащих изменению, и сравнивается с идентификаторами других активных транзакций в системе.

Если DB_TRX_ID сравнивается со свойствами представления чтения и не соответствует видимости, используйте указатель отката DB_ROLL_PTR, чтобы получить DB_TRX_ID в журнале отмены и снова сравнить.

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

В режиме чтения будут сохранены следующие элементы:

Конкретная оценка видимости в режиме чтения заключается в следующем:

1. Если доступная версия DB_TRX_ID свойствоценитьи Read View в m_creator_trx_id ценитьтакой же,Указывает, что дела в настоящее время обращается к записи, которую он изменил.,Поэтому эта версия может быть доступна текущим делам.
2. Если доступная версия DB_TRX_ID Атрибут ценить меньше чем Read View в m_up_limit_id ценить, указывая, что данная версия сгенерирована в текущих делах Read View Уже отправлено ранее,Поэтому эта версия может быть доступна текущим делам.
3. Если доступная версия DB_TRX_ID Атрибут ценить больше или равен Read View в m_low_limit_id ценить, указывая, что данная версия сгенерирована в текущих делах Read View Оно будет зафиксировано позже, поэтому текущие дела не смогут получить доступ к этой версии.
4. Если доступная версия DB_TRX_ID Объект ценить находится в Read View из m_up_limit_id и m_low_limit_id между (включая границы), требуется дальнейшая проверка DB_TRX_ID да Ты здесь?m_ids в списке. если есть в списке, что указывает на то, что версия была сгенерирована при создании ReadView, все еще активна, поэтому доступ к этой версии невозможен; если ее нет в списке, это указывает на то, что версия была сгенерирована при создании ReadView. Read View Когда эта версия создается, издела уже зафиксировано, поэтому к этой версии можно получить доступ.

Схема видимости транзакции:

Прочтите «Просмотр» в разделах RC и RR.

RC и RR созданный под Read View Время другое:

• RC：каждый раз SELECT ReadView генерируется перед данными.
• RR：Прочитал только первый разданныесоздатьReadView,Первый сгенерированный из будет повторно использован позже.

Только из-за RC и Генерация RR Read View Сроки различаются, что приводит к противоречивым данным на двух уровнях.

Например, предположим, что исходное состояние данных следующее:

Имеется три транзакции A, B и C. Порядок выполнения следующий:

Читать «Просмотр» в разделе «RC»

Момент Т4

Давайте посмотрим T4 моментальная ситуация, в это время Транзакция А и Транзакция Б Ни одна из них еще не была отправлена, поэтому идентификатор активной транзакции: m_ids для: [100, 200] четыре Полеизценить следующие:

Момент Т4изцепочка версийследующее：

Согласно принципу видимости, о котором мы упоминали ранее, то, что в конечном итоге увидит транзакция C, должно быть name = «Сяо Мин» данные по следующим причинам:

последняя запись DB_TRX_ID для 100, не менее m_up_limit_id,и не больше, чем m_low_limit_id,И оно не равно m_creator_trx_id。

Попадание в желтую зону:

DB_TRX_ID существовать в m_ids в списке, чтобы его не было видно, следите за цепочкой версия продолжает опускаться.

в соответствии с DB_ROLL_PTR оказаться undo log Предыдущая запись версии в , предыдущая запись DB_TRX_ID все еще 100,все еще Нетвидимый,Продолжайте спускаться.

Продолжить поиск предыдущего элемента DB_TRX_IDдля 1. Удовлетворить 1 < m_up_limit_id,видимый,SoC Найденныйданныедля name = «Сяо Мин» 。

Т6 момент

На Т6 исход изцепочки выглядит следующим образом:

Т6 момент, снова сгенерирует новое Read View,Четыре Полеизценения заключаются в следующем:

в соответствии спринцип видимости,Финал Т6 моментделаC Найденныйданныедля name = "Маленький красный" 。

Т8 момент

Т8 моментизцепочка версийи Т6 момент соответствует из, отличается от Read Посмотреть, автордля Т8 момент переродится в другой Read View,Четыре Полеизценения заключаются в следующем:

в соответствии спринцип видимости,финальный Т8 моментделаC Найденныйданныедля name = "нуб" 。

Подвести итог,делаC здесь RC Данные, видимые в каждый момент под уровнем, следующие:

под Давайте посмотримсмотреть,RR Как он работает на разных уровнях?

Читать Посмотреть под RR

（RR изцепочка версийи RC изцепочка путь такой же, как и из, разница в том, что Read View）

Момент Т4

T4 времяиз ситуации,и R Ситуация в C последовательная:

в соответствии спринцип видимости,финальный Момент Т4делаC Найденныйданныедля name = «Сяо Мин» ,и RC из Момент Т4 соответствует из.

Т6 момент

RR Уровни будут использоваться повторно Read Посмотреть, итак Т6 моменттакжеда：

в соответствии спринцип видимости,Т6 моментмы нашлиделаCquery to изданныевсе еще name = «Сяо Мин» 。

Продолжить просмотр Т8 момент.

Т8 момент

Т8 моментпродолжить повторно использовать предыдущее из Read View。

в соответствии спринцип видимости,Т8 моментаделаC обнаружила, что изданные все еще name = «Сяо Мин» 。

краткое содержание

Мы помещаем транзакцию C в RC и RR Данные, видимые под уровнем, объединены для сравнения:

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

Оглядываясь назад RC и RR Определение уровня изоляции даст вам ощущение просветления:

• Чтение зафиксировано (Читать Committed): Дела можно читать только изданные.
• Повторяемое чтение (Повторяемое Читать): Дела остаются неизменными в режиме просмотра снимков на протяжении всего периода дел, на них не влияют другие дела.

Во всяком случае, здесь RC При уровне изоляции каждое чтение снимка сгенерирует и получит последние новости Read Посмотреть, находясь в RR На уровне изоляции это только при первом прочтении фото создано Читать Посмотреть, после прочтения снимкаgetиз все одинаковые Читать View

Можно ли предотвратить фантомное чтение на уровне RR?

Строго говоря, уровень RR может предотвратить только частичное фантомное чтение.

Прежде всего, фантомное чтение обычно означает, что в той же транзакции второй запрос находит вновь добавленные строки, но первый запрос эти вновь добавленные строки не возвращает.

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

Обратите внимание: MVCC решает только RR Понижение уровня проблема с фантомным чтением, и сейчас Проблема чтения с фантомным чтением решается с помощью Pro Key Lock. То есть RR уровень пройден MVCC+про ключевой замок Чтобы решить большинство проблем с фантомным чтением.

Что вы подразумеваете под частичным решением? Рассмотрим следующий пример:

Предположим, что исходное состояние данных следующее:

Т3время пилы изданные только есть name = «Сяо Мин»,И Т5время,потому что select * from user for update Использовать из сейчас читаю, читаю из — последняя версия изданных, Т5время обнаруживает, что изданные — это два слова, имя соответственно для «Сяо Мин» и «Сяо Чжан».

Поняв приведенный выше пример, посмотрите на следующий пример:

UPDATE Приговор также сейчас читаю, также возникнут фантомные проблемы с чтением, и, наконец, мы видим, что «изданные» — это имя соответственно для «Сяо Мин» и «Сяо Чен».

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

Подвести итог

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

Я надеюсь, что эта статья будет полезна всем студентам и углубит их понимание MVCC и его применения в MySQL. Если эта статья вам полезна, поставьте ей лайк 👍🏻 или прочитайте ее еще раз. Спасибо за чтение!

Нажмите здесь, чтобы увидеть больше.

·················END·················