初识TiDB

背景

前段时间，因为项目需要，开始接触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
复制

‍开启两个事务，如下：

在MySQL中，我们知道在时刻4，由于事务T1还没有提交，会持有id=1这一行的X锁，从而导致事务T2会阻塞。

但在TiDB中，这里就不一样了，很有可能就会出现我在之前提到的问题：即事务T2的insert语句执行成功，但更新语句执行失败。这是我在本地的测试结果：

整个过程事务没有任何异常行为，但如果一不小心这样的代码上线了，嘿嘿，怕是又有程序员要被拿去祭天了。

原因分析

说到这里，就不得不提到TiDB与MySQL的一个重大不同之处，也就是两者的事务模型和隔离级别。

事务模型

TiDB 使用乐观事务模型，在执行 UPDATE、INSERT、DELETE 等语句时，只有在提交过程中才会检查写写冲突，而不是像 MySQL 一样使用行锁来避免写写冲突。类似的，诸如 GETLOCK() 和 RELEASELOCK() 等函数以及 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时还是要更加谨慎。