前言：

在咱们平时做的一个我的项目中，线上环境忽然发现数据库被锁住。导致很多无关数据插入和批改的接口全都瘫痪，我的项目基于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 语句的。