前言

我们在开发一个复杂的系统时可能经常出现这样的场景：比如，A函数中调用了B函数，而A函数和B函数同时都使用了事务，这样就出现了事务嵌套。在MySQL的官方文档中有明确的说明MySQL是不支持嵌套事务的：

Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a START TRANSACTION statement or one of its synonyms.

那我们该如何解决MySQL的事务嵌套问题呢？

解决方法

目前，在PHP圈有两种比较通用的解决方法，一种是以Doctrine为代表的，设置回滚点的解决方法，一种是以Laravel为代表的，控制事务次数的解决方法。

Doctrine的解决方法

Doctrine解决方法的核心就是对回滚点的控制，如下：

Doctrine中开启事务的方法

Doctrine中事务回滚的方法

Doctrine中事务提交的方法

Doctrine用一个_transactionNestingLevel来标识当前嵌套的级别，如果是1，也就是还没有嵌套，那就用默认的方法执行一下START TRANSACTION就ok了；如果大于1，也就是有嵌套的时候，它会帮我们创建一个savepoint。这个savepoint可以理解为一个事务记录点，当需要回滚时我们可以只回滚到这个点。

Laravel的解决方法

相对Doctrine而言，Laravel的解决方法稍微简单粗暴，它巧妙的使用了一个 transactions属性来记录了调用事务的次数。在事务开启，事务提交和事务回滚时，先判断transactions的属性值，只有当transactions的属性值为1时，才进行事务操作。如下：

在开启事务时，我们先判断当前有几个事务，如果是***个，ok，事务开始，否则就啥都不做。

在事务提交时，也判断当前事务个数，如果是***个，ok，提交事务，否则，就只将transactions属性值减一

在事务回滚时，同样先判断当前事务个数，如果是***个，ok，回滚事务，同时将transactions属性值置为0，否则，就只将transactions属性值减一。

在Laravel的解决方法中，在嵌套的内层里面实际上是木有真正的事务的，只有最外层一个整体的事务，虽然简单粗暴，但是也解决了在内层新建一个事务时会造成commit的问题。