Предисловие

После прошлого разговора о трех основных журналах MySQL: undolog, redolog и binlog, необходимо немедленно продолжить статью об анализе транзакций MySQL. Мы знаем, что он участвует в MVCC [Multiple Version Concurrency Control] многопараллельной обработки транзакций. отменить журнал.

Однако мы должны прояснить, что механизм хранения MySQL InnoDB поддерживает транзакции, а механизм хранения MyISAM не поддерживает транзакции.

📚 Количество полных текстов: 9 тыс.+

⏳ Время чтения: 13 минут.

📢 ключевые слова : дела、уровень изоляции транзакции、MVCC、ReadView

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

Что такое транзакция MySQL?

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

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

   Теперь у A и B есть транзакция перевода (при условии, что у них обоих есть 100 000 юаней, Сяо Мин переводит 100 000 юаней Сяо Хуну)
    -- Вычтите 50 000 юаней со счета А.
    UPDATE account SET money = money - 50000 WHERE name = "A";
    -- Счет, соответствующий Сяохуну, увеличился на 100 юаней.
    UPDATE account SET money = money + 50000  WHERE name = "B";
    -- проиллюстрировать:
    Вышеупомянутые два SQL можно распознать как для дела.
   Если какой-либо оператор SQL будет выполнен неправильно и система выйдет из строя, данные будут восстановлены до исходного состояния выполнения этих двух операторов вперед (ROLLBACK).
    Но если оба SQL-запроса будут выполнены успешно, дела(COMMIT) будут отправлены.

Какую проблему решает транзакция?

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

Например, если пользователь А вносит изменения, а пользователь Б также хочет внести изменения в это время, данные могут быть перепутаны или повреждены.

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

характеристики транзакции

Транзакции имеют четыре характеристики ACID: атомарность, согласованность, изоляция и долговечность. Для реализации транзакций необходимо соблюдать эти четыре характеристики.

ACID

атомарность：делаявляется неотъемлемой операционной единицей,Либо полностью выполнить,Или не делайте этого вообще. Если делав операция не удалась,Тогда все дела будут отменены,Откатитесь к тому состоянию, в котором дела начались вперед.

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

Изоляция：дела Реализация должна соответствовать другимдела Исполнение,То есть работа каждого дела независима от работы других дел. Это гарантирует, что дела будут выполняться одновременно.,Не будет никаких взаимных помех, приводящих к несогласованности данных или ненормальным результатам.

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

Понять концепцию ACID таким образом может оказаться непросто. Вот пример для углубления понимания.

Как гарантируется ACID?

Функции транзакций MySQL также реализованы на основе определенных базовых функций. Реализация этих функций выглядит следующим образом:

• 【упорство】проходить redo log (журнал повтора), чтобы гарантировать
• 【атомарность】проходить undo журнал (журнал отката) Чтобы гарантировать
• 【Изоляция】проходить MVCC (управление многоверсионным параллелизмом + блокировка чтения и записи) гарантировать
• [Согласованность] гарантируется сохраняемостью + атомарностью + изоляцией.

Основное использование

В повседневной разработке мы можем выполнять операции транзакций, в большей степени основанные на ORM. Давайте посмотрим, как MySQL использует транзакции.

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

START TRANSACTION; //или ВОЗ BEGIN Давай начнем новые дела

Оператор DML 1;
Оператор DML 2;

ROLLBACK; //дела Откат

СОВЕРШИТЬ; //делапредставлять на рассмотрение

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

ROLLBACK отменит все изменения в транзакции и вернется к состоянию до начала транзакции.

COMMIT делает изменения транзакции постоянными и сохраняет их в базе данных.

Операторы DML (язык манипулирования данными): операторы манипулирования данными, используемые для добавления, удаления, обновления и запроса записей базы данных.

тип транзакции

Транзакции MYSQL делятся на [неявные транзакции и явные транзакции]

Неявные транзакции:

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

Мы можем проверить, включена ли автоматическая отправка, с помощью переменных показа, таких как «autocommit», чтобы указать, что автоматическая отправка включена.

Показать транзакции:

Явные транзакции подразумевают явное указание начала и окончания транзакции в приложении и использование операторов BEGIN, COMMIT и ROLLBACK для управления выполнением транзакции. Синтаксис следующий:

BEGIN;
-- SQL statements
COMMIT;

Проблемы параллелизма нескольких транзакций

Мы знаем, что способ решения проблем в параллельных ситуациях отличается от способа решения проблем в одиночных потоках.,Сервер MySQL поддерживает подключение нескольких клиентов,Это означает, что существует несколько ситуаций параллелизма.,В той же ситуации проблемой является грязное чтение (dirty read), unrepeatable read), фантомное чтение (фантомное чтение).

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

грязное чтение

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

Не перечитывается

Феномен：Нетповторяемое чтениеупоминается вдела Внутри,Прочитайте одни и те же данные несколько раз,Но ценность данных изменилась

фантомное чтение

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

Подводя итог:

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

Вы понимаете разницу между ними? Если вы не уверены, вы можете понять это, пройдя кейс по процессу уровня оплаты.

уровень изоляции транзакции

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

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

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

Соответствующие ситуации различного уровня выполнения платежей следующие:

Уровень изоляции сортируется следующим образом: чем выше уровень изоляции, тем ниже эффективность производительности.

Разный уровень изоляции передача также вызовет различные проблемы при одновременных делах, как показано ниже (грязное чтение、Нетповторяемое чтение、фантомное чтение）

Просто скажи

• [Прочитано незафиксировано] Уровень изоляции: может возникнуть грязное чтение、Нетповторяемое чтениеифантомное чтение Феномен；
• [Читать материалы] Уровень изоляции: может не произойти чтениеифантомное читаю Феномен, но такого не бывает грязное чтение Феномен；
• 【повторяемое чтение】Уровень изоляции: Может возникнутьфантомное чтение Феномен, но невозможно грязное чтениеи Нетповторяемое чтение Феномен；
• [Сериализация] Уровень изоляции: Этого не произойдет грязное чтение、Нетповторяемое чтениеифантомное чтение Феномен

Как установить уровень изоляции

Давайте проверим, повторяется ли уровень изоляции MySQL по умолчанию. Вы можете проверить это с помощью переменных show, например команды «transaction_isolation».

// mysql 5.7-назад Просмотр уровня изоляции
show variables like 'transaction_isolation'; 

+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+

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

1: Его можно установить в файлах конфигурации MySQL my.cnf и my.ini.

Например, установите для него значение: transaction-isolation=REPEATABLE-READ # Повторяемое чтение.

2: Используйте SET TRANSACTION Команда изменяет уровень одного или всех новых соединений изоляции транзакции

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE}

например:
set session transaction isolation level read committed;

• Ключевое слово Без GLOBAL или SESSION указывает на установку уровня изоляции следующих дел;
• использовать GLOBAL Ключевое слово указывает уровень глобальных настроек. изоляции транзакции,настраиватьназадизуровень изоляции Обмен вступает в силу для всех новых подключений к базе данных;
• использовать SESSION Ключевое слово указывает текущий уровень настроек подключения к базе данных. изоляции передача, действует только для текущего прямого соединения;
• Любой клиент волен изменить уровень текущей сессии форварда. изоляции транзакции,Можно поменять посреди дел.,Также возможно изменить уровень изоляции следующих дел.

Анализ различных уровней изоляции

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

// структура таблицы
CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT COMMENT 'ID пользователя',
  `name` varchar(32) COLLATE utf8_bin DEFAULT NULL COMMENT 'Имя',
  `point` int DEFAULT '0' COMMENT 'интеграл',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

//Вставляем запись
INSERT INTO user (name, point) VALUES('xiaoxu', 100)

Читать незафиксированные (читать uncommitted）：вопрос（может случитьсягрязное чтение、Нетповторяемое чтениеифантомное чтение Феномен）

// Первый генералуровень изоляции транзакцииset для чтения без фиксации read uncommitted
set session transaction isolation level read uncommitted;

Интерпретация явлений

Начать два дела А, Б,Значение, запрошенное дела А, равно 100.,Затем выполните Update и установите точку для150.,дела А в настоящее время не отправлено,При запросе делаB значение было 150. На этот раз дела Б прочитало 150 о продолжении своего дела.,Но дела А это придурок,Данные дела Б — грязные данные (грязное чтение)

И если значение, запрошенное транзакцией A в начале, равно 100, а транзакция B обновляет значение Point до 200, значение, запрошенное транзакцией A, снова равно 200. После отката транзакции B два результата чтения транзакции A становятся несовместимыми. .(неповторяемый), здесь больше никаких рисунков.

И фантомное чтение здесь тоже не решается.

Прочитать зафиксировано (прочитать committed）：может случиться Нетповторяемое чтениеифантомное чтение Феномен

// Также сначала поставьте уровень изоляции транзакцииset для чтения без фиксации read committed
set session transaction isolation level read committed;

Интерпретация явлений

Начать два дела А, Б,Значение, запрошенное дела А, равно 100.,В это время дела Б меняет стоимость балла на 150 (дела не отправлено),Значение, запрошенное дела А, по-прежнему равно 100.,И дела Б отправлены назад,дела А обнаружил, что значение равно 150. делаAРезультаты двух запросов при одинаковых условиях противоречивы,Хоть и решено грязно читал, но не смог это сделать повторяемое читая, то же самое невозможно решить фантомное чтение。

повторяемый read）：может случитьсяфантомное чтение Феномен

// Также сначала поставьте уровень изоляции транзакцииset для чтения без фиксации repeatable read
set session transaction isolation level repeatable read;

Интерпретация явлений

повторяемое чтение Этого не произойдет грязное чтениеи Нетповторяемое проблемы с чтением, но может случиться фантомное вопрос чтения.

Запустите две транзакции A и B. Транзакция A запрашивает точку > Запись 50 получает запись, и транзакция B запрашивает точку. > 50из Запишите такжедазапись,В это время дела А вставляет запись с точкой=150.,и представить дела,в это времяделаBЗапросить еще разpoint>50из Записывать,те же условия,Появятся две записи.

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

сериализуемый：грязное чтение、Нетповторяемое чтениеифантомное чтение Феномен Все【Нетможет случиться】

Сериализация — 4 вида уровня изоляции Лучший эффект изоляции при передаче, решено грязное чтение、повторяемое чтение、фантомное чтениеизвопрос,Но худший эффект,Это меняет выполнение дел на последовательное исполнение.

Курс дает пример того, что происходит на разных уровнях изоляции. Я думаю, что все знакомы с проблемами. параллелизма нескольких Уровни изоляции транзакций и дел будут более понятны. Давайте изменим идею: разный уровень. изоляции Трансляция предназначена для решения различных проблем, которые могут возникнуть при одновременном выполнении нескольких дел, поэтому ее легче понять!

Следует отметить, что уровень InnoDB по умолчанию изоляции транзакциида【повторяемое чтение], но InnoDB в некоторых сценариях обходит фантомное на этом уровне. Проблема с чтением, давайте рассмотрим два решения. чтение снимка Обычный выбор заявление：даНа основе MVCC Многоверсионный метод управления параллелизмом решает фантомное чтение сейчас читаю（select ... for update ждатьзаявление）,дапроходить next-key метод блокировки (блокировка записи + блокировка пробела) решает фантомное чтение

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

На самом деле MySQL имеет два режима чтения данных, а именно: «Сейчас читаю» и «Чтение снимка».

чтение снимка：обычноизselectзаявление(Нетвключать select ... lock in share mode; select ... for обновить;), то есть Разблокирована операция выбора Все приняты чтение выкройка снимка. MySQL MVCC (Multiversion Concurrency Control) механизм, обеспечивающий согласованность считываемых данных. Чтение данных не требует блокировки и не будет заблокировано другими транзакциями.

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

• read committed (читать Представленное): дела создают ReadView каждый раз, когда оно выбрано.
• repeatable read (повторяемое чтение): ReadView создается, когда дела выбираются в первый раз, назад продолжает использовать

сейчас читаю：Модификация данныхиздействовать(update、insert、delete) Все приняты Текущий режим чтения обеспечивает согласованность данных путем [блокировки] считанных данных (индексных записей), например:

select ... lock in share mode; 
select ... for update; 
insert; update;
delete;

Какая связь между сейчас читаю, читаю снимку и MVCC?

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

ок, ты понимаешь? Сяо Сюй теперь тоже заполнил пробелы и понял.

Управление многоверсионным параллелизмом MVCC

Какую проблему решили

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

Как достичь

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

Скрытые поля

InnoDB добавляет три Скрытых в каждую строку данных. поля,уникальный номер строки,Номер версии при создании записи,Номер версии, записывающий откат,следующее:

Вот посмотрите на старые фотографии статьи, использованные форвардом.,увлекающийсяиз Студенты могут вернуться и посмотреть【портал：Структура хранения записей строк MySQL InnoDB】

db_row_id: 6-байтовый, неявный идентификатор автоматического увеличения (скрытый первичный ключ). Если таблица данных не имеет первичного ключа, InnoDB автоматически сгенерирует кластерный индекс с DB_ROW_ID.

db_trx_id: 6 байт, идентификатор последней измененной (измененной, вставленной) транзакции: записывает идентификатор транзакции, создавшей эту запись и последней изменившей запись, которая является указателем.

db_roll_ptr: 7 байт, указатель отката, указывающий на предыдущую версию этой записи (предыдущая версия хранится в сегменте отката).

Отменить журнал

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

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

Поскольку журнал отмены записывает информацию о предыдущей версии, измененной транзакцией, если она откатывается из-за системной ошибки или операции отката, информация журнала отмены может использоваться для отката к состоянию до ее изменения.

увлекающийсяиз Студенты могут вернуться и посмотреть之впередоMySQLбревноизстатья【портал：В сочетании с процессом обновления MySQL обратите внимание на undolog, redolog и binlog.】

Просмотр просмотра – просмотр чтения

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

ReadView в основном содержит четыре важных содержимого, а именно:

Creator_trx_id — идентификатор транзакции, которая создает это представление чтения, то есть идентификатор транзакции создателя, а не trx_id в записи!

Примечание. Идентификатор транзакции будет присвоен транзакции только при внесении изменений в записи в таблице (при выполнении операторов INSERT, DELETE и UPDATE). В противном случае значение идентификатора транзакции в транзакции, доступной только для чтения, по умолчанию равно 0.

m_ids : указывает коллекцию идентификаторов транзакций, активных в текущей системе на момент создания ReadView. («Активный» означает, что он был запущен, но еще не отправлен).

min_trx_id : представляет наименьшую транзакцию среди активных транзакций на момент создания ReadView. ID

max_trx_id：означает создатьReadViewкогда система должна быть назначена на следующийделаизidценить,когдавпередмаксимумделаID+1

Логика оценки характера записей данных заключается в сравнении проводимогоreadview с [Скрытыми поляtrx_id] записей строк.

Когда транзакция обращается к записи, как она определяет видимость записи?

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

Соблюдаются следующие правила сопоставления видимости:

Описание правила:

• trx_id = создатель_trx_id: если trx_id Значение равно createRead ViewизделаId,Тогда дела последней операции, записанные в данных, — это когда форварддела,Эта версияиз Записывать对когдавпередделавидимый
• trx_id < min_trx_id: если trx_id значение меньше, чем Read View в min_trx_id , указывающий, что эта версия записи создается Read View впередужепредставлять на рассмотрениеизделарожденныйстановитьсяиз,так Эта версияиз Записывать对когдавпередделавидимый
• trx_id >= max_trx_id: если trx_id значение меньше, чем Read View в min_trx_id , указывающий, что эта версия записи создается Read View назадТолько началосьизделарожденныйстановитьсяиз,так Эта версияиз Записывать对когдавпередделаНетвидимый
• min_trx_id <= trx_id < max_trx*id: Решение *trx_id Есть ли он в текущей коллекции идентификаторов форварддела (m_ids)?
• Если в m_ids, это представляет чтение Viewрожденныйстановитьсявремя,Это дело все еще активно,Еще нет фиксации,Версия, записанная в форддела, не встречается
• если не в m_ids,Это означает,Это дело уже было зафиксировано до создания представления чтения.,Версия записана в форвардделавидимый

Ладно, вот и закончилось знакомство с MVCC. Друзья, потратьте немного времени на его анализ на основе графика!

Анализ уровня изоляции MVCC

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

read committed (читать представленное)：делакаждый разselectсоздано, когдаReadView,Значения четырех полей в каждом ReadView разные

повторяемое чтение：делапервыйselectсоздано, когдаReadView,назад повторно использует этот ReadView

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

Прочитать представленный анализ

Давайте посмотрим на пример процесса,делаA,Б почти коллеги запрашивают запись,потому чтодлядаread committed (читать представленное) Уровень изоляции, поэтому каждый выбор будет генерировать отдельный ReadView.

Блок-схема запроса транзакций A и B выглядит следующим образом:

Мы рассматриваем идентификаторы транзакций 27 и 28 соответственно. A и B читают запись с trx_id 26. Транзакция A выполнила два запроса, и второй раз был после отправки транзакции B. Мы дважды запрашиваем, чтобы сгенерировать различия ReadView:

В это время транзакция А может запросить, что значение балла равно 100. Соответствие db_trx_id < правило min_trx_id, чтобы можно было запросить запись данных текущей версии, Однако перед вторым чтением транзакция B изменила пару и отправила транзакцию. В этот момент видимые данные цепочки версий следующие:

В это время значение скрытой записи db_trx_id в записи таблицы равно 28, что соответствует правилам. min_trx_id <= db_trx_id < maxtrxid（27<=28<29）,И делаID текущей версии данных форварда отсутствует в активной коллекции делam_ids в текущей системе форварда.,Вы можете посмотреть данные текущей версии форварда,То есть, Стоимость балла 150 можно найти.

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

Повторяемый анализ чтения

Повторяющееся чтение создает ReadView при первом выборе транзакции, а затем повторно использует этот ReadView. Разница между этим и фиксированным чтением заключается в следующем.

Выполнение транзакций A и B аналогично процессу чтения отправленных данных. Это два запроса, отправленные транзакцией до и после изменения одной и той же записи, но результаты двух запросов одинаковы, а значение равно 100. .

Однако эти два запроса используют один и тот же ReadView, и результаты следующие:

Видно, что все соответствует правилам. min_trx_id <= db_trx_id < max_trx_id（27<=27<29）,И делаID текущей версии данных форварда отсутствует в активной коллекции делam_ids в текущей системе форварда.,такда Нет Вы можете посмотреть данные текущей версии форварда,То есть дляwhatdelaB представил,Но значение точки, найденной во втором запросе, по-прежнему равно 100.

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

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

Прочитав статью, у вас могут быть разборки. Вы в принципе разбираетесь в транзакциях MySQL. Вы победили еще одну точку знаний и можете двигаться вперед с высоко поднятой головой! (О(∩_∩)О хаха~)

Понимание написания: На самом деле, прежде чем писать статью, я либо забыл о большом содержании, либо оно было недостаточно ясным. У меня есть предыдущая статья, но нет продолжения. Самое главное — разобраться с содержанием. Прежде чем писать, составьте конспект, иначе я это потеряю и ход вашей мысли нарушится!

👨👩Друзья, надеюсь, эта статья будет вам полезна~🌐

Добро пожаловать, ставьте лайк 👍, собирайте 💙, подписывайтесь 💡 и поддержите нас три раза подряд~🎈

Я Сяо Сюй, увидимся в следующий раз~🙇💻

Справочная статья:

Подробное объяснение транзакций MySQL_транзакции mysql_блог Шучуана-блог CSDN

Сочетание изображений и текста поможет вам понять InnoDB MVCC-Tencent Cloud Developer Community-Tencent Cloud

Подробный анализ принципа реализации MySQL MVCC, интервьюер сразу же назвал его экспертом после прочтения Сообщество производительности HeapDump |