背景
前段时间，因为项目需要，开始接触TiDB。TiDB高度兼容MySQL，官方宣称无需修改任何代码，就可以实现无缝迁移。今天就分享一个我们项目中的实际案例，然后谈谈两者之间的一些差异。
先简单介绍下场景，我们的场景和秒杀场景比较类似，代码如下（实际秒杀场景应该是库存校验通过后再创建订单，这里只是借此说明decreaseStock()方法会并发更新同一行数据）：
tx.begin()
err := createOrder()
if err != nil {
tx.rollback()
return
}
// high concurrency
effectRows, err := decreaseStock()
if err != nil || effectRows == 0 {
tx.rollback()
return
}
tx.commit()
乍一看，这段代码似乎没什么问题，事务异常即回滚，全部成功才提交事务。然而测试过程中却发现，并发场景下，会偶现订单创建成功了，但是库存并没有扣减的情况。
场景复现
为了模拟这种场景，我们先创建两张表，并做初始化：
CREATE TABLE `t` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`a` int(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
insert into t values (1,10);
CREATE TABLE `t1` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`a` int(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
开启两个事务，如下：
| T1 | T2 | |
|---|---|---|
| 1 | begin | begin |
| 2 | insert into t1 values(1, 1); | insert into t1 values(2, 2); |
| 3 | update t set a = a - 6 where id = 1 and a - 6 >= 0; | |
| 4 | update t set a = a - 7 where id = 1 and a - 7 >= 0; | |
| 5 | commit | |
| commit |
在MySQL中，我们知道在时刻4，由于事务T1还没有提交，会持有id=1这一行的X锁，从而导致事务T2会阻塞。
但在TiDB中，这里就不一样了，很有可能就会出现我在之前提到的问题：即事务T2的insert语句执行成功，但更新语句执行失败。这是我在本地的测试结果：
整个过程事务没有任何异常行为，但如果一不小心这样的代码上线了，嘿嘿，怕是又有程序员要被拿去祭天了。
原因分析
说到这里，就不得不提到TiDB与MySQL的一个重大不同之处，也就是两者的事务模型和隔离级别。
事务模型
TiDB 使用乐观事务模型，在执行
UPDATE、INSERT、DELETE等语句时，只有在提交过程中才会检查写写冲突，而不是像 MySQL 一样使用行锁来避免写写冲突。类似的，诸如GET_LOCK()和RELEASE_LOCK()等函数以及SELECT .. FOR UPDATE之类的语句在 TiDB 和 MySQL 中的执行方式并不相同。所以业务端在执行 SQL 语句后，需要注意检查COMMIT的返回值，即使执行时没有出错，COMMIT的时候也可能会出错。
隔离级别
TiDB 实现了快照隔离 (Snapshot Isolation) 级别的一致性。为与 MySQL 保持一致，又称其为“可重复读”。
处于可重复读隔离级别的事务不能并发的更新同一行，当时事务提交时发现该行在该事务启动后，已经被另一个已提交的事务更新过，那么该事务会回滚并启动自动重试。
MySQL 可重复读隔离级别在更新时并不检验当前版本是否可见，也就是说，即使该行在事务启动后被更新过，同样可以继续更新。这种情况在 TiDB 会导致事务回滚，导致事务最终失败，而 MySQL 是可以更新成功的。MySQL 的可重复读隔离级别并非 Snapshot 隔离级别，MySQL 可重复读隔离级别的一致性要弱于 Snapshot 隔离级别，也弱于 TiDB 的可重复读隔离级别。
到这里，我们心里似乎就有那么一点点眉目了。因为TiDB并没有使用类似MySQL那样的行锁机制，而是采用了乐观事务模型，所以在上面的例子中，事务T2在时刻4不会被阻塞。而是会在在事务提交过程中检查写写冲突，那现在的问题是，为什么在我们上面的例子中，事务T2在提交时却没有检测到冲突而提交成功了呢？
而这是因为事务重试引起的。
在最新的TiDB3.0版本中，事务默认不会重试。同时我们从DBA处了解到，我们的TiDB虽然是3.0版本，但却是从2.1版本升级上来的，为了保持一致性，事务重试还是保持了2.1版本的特性，而在2.1版本中，事务失败是会自动触发重试的。
在我们上面的例子中，事务T2在提交时没有检测到冲突正是事务重试引起的。
查看参数配置的确如此：
为了进一步验证这一猜想，我们关闭TiDB的事务重试机制
SET @@global.tidb_disable_txn_auto_retry = on;
然后重新执行上述例子，此时TiDB表现如下：
我们看到，事务T2在时刻4依然没有被阻塞，但是提交时提示写写冲突。同时从最后结果也可以看到事务T2完成了回滚。
由于这个冲突只会在事务提交时才会提示，所以我们上面的代码还有一处需要优化，就是需要检查commit的返回值，commit出错则进行事务回滚，这就是前面提到的TiDB乐观事务机制。
tx.begin()
err := createOrder()
if err != nil {
tx.rollback()
return
}
// high concurrency
effectRows, err := decreaseStock()
if err != nil || effectRows == 0 {
tx.rollback()
return
}
// check commit result
err := tx.commit()
if err != nil {
tx.rollback()
return
}
当然，最后考虑到集群特性一致性，我们并没有关闭事务重试机制，而是通过引入分布式锁来解决了并发问题。
其它
MVCC
与MySQL一样，TiDB也使用MVCC机制管理版本，但与MySQL不同的是，在TiDB中，通过设置一个会话级别的系统变量，可以直接读取历史数据。
set @@tidb_snapshot="2019-08-01 08:00:00";
设置该变量后，select语句将可以查询到该时间点之前最新版本的变量，在该时间点之后更新的变量将不可见。将该变量置空则可以读取到最新变量。
执行计划
TiDB的执行计划输出格式与MySQL有较大差异，具体个字段的含义可以参考官方文档。
总结
本文主要是通过一个案例分析了TiDB和MySQL在事务模型和隔离级别上的一些差异。事实上，虽然协议兼容，但两者的区别远不止这一点，在使用TiDB时还是要更加谨慎。
