编辑:业余草
来源:https://www.xttblog.com/?p=4922
熟悉 Oracle 的都知道 Oracle mvcc 里有一个概念:query restart,因此我 3 月份的时候发了一个微博!
我的回答:这是 MySQL MVCC 的一个设计缺陷:
虽然 SQL-92 规定了四种隔离级别,但是在引入 MVCC 后,RC/RR 都是 snapshot isolation 下的变体。至于对隔离性和一致性的吐槽,引用沈洵的话:“快照读以更低的代价实现了更高的并发度,却不得不委身在原有事务框架内。其实 ACID 也只是一个标准,并非真理。”
既然是 snapshot isolation,MySQL 有什么问题呢,直接上案例:
准备工作:
create table mvcc(x int auto_increment primary key,y int default 1);
insert into mvcc(y) select 1 from mvcc; -- many times
Query OK, 2097152 rows affected (13.24 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
RC/RR && autocommit = 0
按照 snapshot isolation 来说 session2 的 trxid 大于 session1 的 trxid,从而 session2 的修改对 session1 应该是不可见的:即 session1 应该更新 0 行,但是 MySQL 在这里却对 y=2 进行了更新。
MySQL 官方在 5.5+ 的文档也针对该问题做出了 Note:
The snapshot of the database state applies to SELECT statements within a transaction, not necessarily to DML statements. If you insert or modify some rows and then commit that transaction, a DELETE or UPDATE statement issued from another concurrent REPEATABLE READ transaction could affect those just-committed rows, even though the session could not query them. If a transaction does update or delete rows committed by a different transaction, those changes do become visible to the current transaction.
根本原因在于 MySQL 在 update/delete/insert/select for update/select lock in share mode 时进行的是 current read(selectlocktype != LOCK_NONE) 而非 consistent read。而 Oracle 解决这个问题的方式是对比 current read 和 consistent read 来决定是否进行 query restart(细节参考 tom oracle 艺术);对于该案例,session1 在 T2 时更新到 x=3000000 时发现 y 发生了变化从而回滚了这个变更并进入 query restart,最终结果就是在 T3 时更新了 0 行。
因此,如果业务依赖事务但是又不清楚具体数据库的实现细节,很容易就掉到坑里了;比如这个案例,就产生了"错误的"更新。
下面针对 MySQL RR 给出一个非谓词更新的一个案例:如果不理解这块事务,在T3时想当然就会觉得结果应该是 6000,可能就犯错了。
RR && autocommit=0
总的来说事务的水还是比较深的,当面对分布式时,又是另外一番烧脑。