Laravel 7偶发"There is already an active transaction"事务错误求助

针对你遇到的Laravel 7.30.6 + MySQL 8.0.27社区版中偶发出现该错误、且报错时数据已写入的情况，给出以下排查方向和解决方法：

一、重试机制导致的事务残留 #

你使用了DB::transaction($closure, 5)的重试特性，Laravel在重试时如果前一次事务因隐性异常（如连接波动、锁等待）未正确完成回滚/提交，复用同一数据库连接时就会触发该错误。而数据已写入，说明第一次事务实际已经提交，但重试逻辑仍在执行。

排查： #

• 开启Laravel数据库日志：在config/database.php中对应数据库配置里添加'log' => true，或通过DB::listen监听SQL语句，记录每次事务的begin、commit、rollback动作，看重试时连接的状态变化。
• 查看MySQL通用日志（general_log），追踪报错时对应连接的事务状态，确认是否存在未结束的事务。

解决： #

• 手动控制重试逻辑，替代Laravel自带的重试，确保每次重试前重置连接状态：

$attempts = 5;
$result = null;
do {
    try {
        // 重试前检查并清理残留事务
        if (DB::connection()->getPdo()->inTransaction()) {
            DB::rollBack();
        }
        DB::beginTransaction();
        $result = DB::table('tableName')->insertGetId($insertArray);
        DB::commit();
        break;
    } catch (\Exception $e) {
        DB::rollBack();
        $attempts--;
        if ($attempts === 0) {
            throw $e;
        }
        sleep(1); // 重试前短暂休眠，避免瞬时冲突
    }
} while ($attempts > 0);

二、数据库连接池的连接复用问题 #

如果项目使用了数据库连接池（包括Laravel自带连接池或第三方扩展），连接归还到池时若未正确重置事务状态，下一次获取该连接时会发现已有活跃事务。

排查： #

• 检查config/database.php中的连接配置，确认是否开启了连接池相关设置；若使用第三方连接池包，查看其文档确认连接回收逻辑。
• 报错时执行SELECT * FROM information_schema.innodb_trx;，查看是否有长时间未提交的事务，对应到具体数据库连接。

解决： #

• 在请求生命周期结束时清理事务状态，比如在全局中间件的terminate方法中添加：

public function terminate($request, $response)
{
    if (DB::connection()->getPdo()->inTransaction()) {
        DB::rollBack();
    }
}

• 调整连接池的闲置超时时间，让长时间未使用的连接被自动回收，减少残留事务的连接被复用的概率。

三、隐性事务未正确收尾 #

代码中其他位置（如全局中间件、模型事件、观察者）可能开启了事务，但未处理异常导致事务残留，后续执行你的插入事务时冲突。

排查： #

• 检查所有手动开启事务的代码，确认是否都有对应的try-catch块处理异常并回滚。
• 排查模型的creating/created/saved等事件和观察者，看是否存在未正确收尾的事务操作。

解决： #

• 所有事务操作优先使用DB::transaction闭包形式，而非手动beginTransaction()/commit()/rollback()，闭包会自动处理异常回滚。
• 对于必须手动管理的事务，严格保证commit()和rollback()的执行路径覆盖所有异常场景。

四、MySQL事务机制相关问题 #

MySQL 8.0默认隔离级别为REPEATABLE READ，可能存在间隙锁、事务超时等情况，导致事务未正常结束，进而引发冲突。

排查： #

• 查看MySQL的错误日志，检查是否有事务超时、死锁相关的报错记录。
• 报错时查询information_schema.innodb_trx表，查看未提交事务的详情，判断是否因锁等待导致事务挂起。

解决： #

• 调整MySQL的innodb_lock_wait_timeout参数（默认50秒），根据业务场景缩短超时时间，避免事务长时间挂起。
• 优化插入前的查询逻辑，避免大范围查询引发间隙锁，减少事务冲突概率。

内容的提问来源于stack exchange，提问作者Jack M.