Прежде всего:
Для TiDB только поддержка SNAPSHOT (последняя версия)
Уровень изоляции транзакций . но он может видеть только подтвержденные данные до транзакции .
и TiDB также не будут обновлять одно и то же значение в транзакции ,
как MySQL и SQL Server и т. д.
Для MySQL , когда используется уровень изоляции READ COMMITTED , он
будет читать совершенные данные, поэтому он будет читать другие транзакции
зафиксированные данные.
Так как ваш фрагмент кода:
TiDB раунд 1 рабочий процесс:
T1 T2
+--------------------+
| transaction start |
| (b = 0) |
+---------+----------+
|
|
| +------------------------------+
| <----------------------+ update `b` to 2, and commit |
| +------------------------------+
|
|
+-----------+-----------+
| select b should be 0, |
| since tidb will only |
| get the data before |
| transaction committed |
+-----------+-----------+
|
v
+------------------------------+
| update value to 0 |
| (since 0 is equal to the |
| transaction started value, |
| tidb will ignore this update)|
+------------------------------+
+
|
|
|
v
+-------------------------+
|so finally `b` will be 2 |
+-------------------------+
TiDB раунд 2 рабочий процесс:
T1 T2
+--------------------+
| transaction start |
| (b = 2) |
+---------+----------+
|
|
| +------------------------------+
| <----------------------+ update `b` to 2, and commit |
| +------------------------------+
|
|
+-----------+-----------+
| select b should be 2, |
| since tidb will only |
| get the data before |
| transaction committed |
+-----------+-----------+
|
v
+------------------------------+
| update value to 0 |
| (since 0 is not equal to 2 |
+------------------------------+
+
|
|
|
v
+-------------------------+
|so finally `b` will be 0 |
+-------------------------+
Так что для TiDB будет выводить как:
0, 2, 0, 2, 0, 2...
MySQL рабочий процесс:
T1 T2
+----------------------+
| transaction start |
| ( b = 0 ) |
+-----------+----------+
|
|
|
| +---------------------------+
| <----------------------+update `b` to 2, and commit|
| +---------------------------+
|
|
v
+--------------------------------------------+
| select b should be 2, |
| since use READ COMMITTED isolation level, |
| it will read committed data. |
+---------------------+----------------------+
|
|
v
+--------------------+
| update value to 0 |
+--------------------+
+
|
|
|
v
+--------------------------+
| so finally `b` will be 0 |
+--------------------------+
так MySQL может непрерывно выводить:
2, 2, 2, 2...
Последнее слово
Я думаю, что это очень странно для TiDB до пропустить обновление с тем же значением в Транзакции , но когда с другим значением он также может быть успешно обновлен, например, мы можем обновить b
до другого значения в цикле, мы всегда можем получить последнее изменение b.
Так что, может быть, лучше сохранить такое же поведение между одинаковым значением и другим значением .
Я создал проблему для этого:
https://github.com/pingcap/tidb/issues/7644
Ссылки:
https://github.com/pingcap/docs/blob/master/sql/transaction-isolation.md