Разговор о MVCC и блокировках следующего ключа

предисловие

В прошлой статье упоминалось, что уровень изоляции RR MySQL решает проблему фантомного чтения через MVCC+Next-key Locks, сейчас я расскажу вам, что это за два механизма.

MVCC (управление параллелизмом нескольких версий)

Большинство реализаций транзакционного механизма хранения MySQL не являются простыми блокировками на уровне строк. Основываясь на соображении улучшения параллелизма, управление параллелизмом нескольких версий (MVCC) обычно реализуется одновременно, включая Oracle и PostgreSQL. Однако реализации различаются.

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

Делятся на оптимистичный (оптимистичный) контроль параллелизма и пессимистический (прессимистический) контроль параллелизма.

Как работает MVCC:

номер версии

скрытый столбец

Как MVCC работает на уровне изоляции REPEATABLE READ:

1. SELECT

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

2. INSERT

3. DELETE

4. UPDATE

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

MVCC работает только при двух уровнях изоляции: COMMITTED READ (фиксация чтения) и REPEATABLE READ (повторяемое чтение).

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

Чтение моментального снимка и текущее чтение

1. Чтение снимка

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

2. Текущее чтение

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

select * from table where ? lock in share mode; 
select * from table where ? for update; 
insert; 
update; 
delete;

Как исправить галлюцинации

InnoDB имеет три алгоритма блокировки строк:

Record Locks

Gap Locks

SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;

Next-Key Locks

MVCC не может решить проблему фантомного чтения, и для решения этой проблемы существуют блокировки Next-Key. На уровне изоляции REPEATABLE READ использование MVCC + Next-Key Locks может решить проблему фантомного чтения.

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

CREATE TABLE `test` ( 
`id` int(11) primary key auto_increment, 
`xid` int, KEY `xid` (`xid`) ) 
ENGINE=InnoDB DEFAULT CHARSET=utf8; 
insert into test(xid) values (1), (3), (5), (8), (11);

Посмотрите на картинку ниже, чтобы понять:

Заблокированный диапазон оператора SQL — (5,8), а следующий диапазон значений ключа — (8,11], поэтому при вставке значений между 5 и 11 он будет заблокирован и потребует ожидания. То есть: вставка 5, 6, 7, 8, 9, 10 будет заблокирована.Вставка значений вне этого диапазона является нормальным явлением.

резюме

В этой статье обобщаются три алгоритма блокировки строк в MVCC и InnoDB. Эти знания относятся к базовому уровню MySQL. При таком понимании использование MySQL может быть более удобным в будущем. Последний вопрос выше: почему он не будет заблокирован когда xid равен 11. Все еще есть немного непонимания.Объяснение, данное другими блоггерами, заключается в том, что идентификатор является самовозрастающим, а дерево B + innodb упорядочено, поэтому оно не будет блокировать последующие вставки. Это объяснение все еще требует, чтобы я вернулся и посмотрел на подробное описание реализации блокировок следующего ключа в «mysq technology Insider», прежде чем дать более разумное объяснение.