как может работать mv cc при изменении первичного ключа? - PullRequest
Новая
       13

как может работать mv cc при изменении первичного ключа?

0 голосов
/ 14 февраля 2020

В документе MV CC говорится, что когда «запрос на выборку» находит записи, он сравнивает ID транзакции со своим собственным идентификатором, чтобы определить, можно ли просмотреть данные и следует ли восстановить записи истории из журнала повторов. Мой вопрос: что, если он не может найти оригинальные записи и как он может поддерживать постоянное чтение?

Рассмотрим следующий пример: 

create table tb_a (id bigtint not null primary key auto_increment, name varchar(100) not null default "");
 // isolation level is RR

// transaction 1
select * from tb_a where id = 1;  // it returns (1, "a")

// transaction 2
// another trx update the first line with its primary key
update tb_a set id = 3 where id = 1;
commit;

// transaction 1
select * from tb_a where id = 1; // still gets (1, "a")

первичный ключ с идентификатором фильтра = 1 не может найти строку, поскольку записи истории находятся в журнале повторов, а обновления в innodb происходят на месте. Так как же innodb относится к такого рода вещам и сохраняет последовательность?

1 Ответ

0 голосов
/ 22 февраля 2020

Изменение столбца PK, вероятно, является «удалением» старой записи и «вставкой» новой строки. Я думаю, это подразумевает, что что-то осталось в таблице, но помечено как удаленное (до очистки после фиксации от обеих транзакций).

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

Каждая версия каждой строки (старая / новая) имеет идентификатор транзакции. Итак ...

Повторяемое чтение:

Когда транзакция начинается, ей присваивается «идентификатор транзакции». Это монотонно увеличивающийся порядковый номер для определения строк, которые могут быть изменены. Для изоляции транзакции = RR запросы могут «видеть» только те строки, которые имеют этот идентификатор trx (или более старый). Это объясняет, почему ваш последний SELECT видит, что он делает. И, обратите внимание, этот запрос фактически (насколько я знаю) повторно выполняется.

Ваш другой txn имел более высокий идентификатор trx. Он создал «более новую» копию строки. Итак, по крайней мере, было две копии этого ряда. Режим изоляции и идентификатор trx определяют, какую строку каждая транзакция может «видеть».

...