浅谈一下 ThinkPHP5.1 实现事务嵌套的特性

前言：

在我们平时做的一个项目中，线上环境突然发现数据库被锁住。导致很多有关数据插入和修改的接口全都瘫痪，项目基于 ThinkPHP5.1。报错的时候，我们发现了一条 sql 错误日志，如下。

根据错误信息提示，是说有一个事务回滚时没有找到 savepoint 的暂存点。所以问题应该是事务嵌套导致的，目前 ThinkPHP5 封装的数据层方法是有对事务嵌套进行处理。而 MYSQL 到底支不支持事务嵌套呢？伪代码如下。

执行完后出现了操作 1 的数据真正写入，只有操作 2 的数据回滚了。在第一个事务没有提交或回滚时，再开启第二个事务时，会自动提交第一个事务。 这明显不符合心理预期，而且也无法回滚一部分操作。首先，调用多次 begin 的写法，在 MySQL 里肯定是无法首先事务嵌套的。

抱着疑问，我去网上也查了很多类似的问题。却意外的发现关于“解决事务嵌套的方法”都如此的雷同，清一色的 “开启事务时候使用单例，检查事务是否存在”。（蒙圈……）

继续回到 MYSQL 是否支持事务嵌套，最后我了解到 MySQL 中有一个叫 savepoint 和 rollback to 的语句。于是我顺手举了个例子。

上面有 3 张表，分别有不同的更新操作和最后的插入。但是最后只回滚到 P1，执行完 commit 后，我发现只有 p1 位置的操作做了更新，后面的修改和插入全都没生效。可能 savepoint 和 rollback to 语句并不能称之为事务嵌套，也不能说 MySQL 是支持还是不支持事务嵌套。总之通过 savepoint 和 rollback to，是可以用来达到一些事务嵌套特性的。

根据我们项目的日志，我也试着复现一下，故意 rollback to 到一个不存在的点上，最后 commit 时发现，数据库的第一条 sql 修改了，后面插入语句也添加成功了。

ThinkPHP5.1

所以再回到 ThinkPHP5 框架实现的事务嵌套，于是我打开了框架的 Connection 抽象类。最主要的就是下面部分了。

\1. 开启事务。

开启事务的部分加了次数累加，只要在代码块中使用了 transaction 就会被记录并叠加，当只有 1 时，才执行 sql 的 begin，否则就 savepoint 记录一个保存点。

\2. 提交事务。

判断了只有等于 1 才对事务进行提交，也就是在代码中最后面的 commit 才生效，使用一次减一次嵌套计数。initConnect 方法主要是对分布式数据库和单机对读写连接的判断。

\3. 回滚事务。

回滚主要也是当计数等于 1 才让 sql 执行 rollback，否则(也就是嵌套了)就让连接资源回滚到执行的保存点。它里面的就是使用的 rollback to p1 语句的。