如何使用ThinkPHP进行MySQL事务处理及操作技巧详解？

本文共计1096个文字，预计阅读时间需要5分钟。

ThinkPHP与MySQL事务可用，但默认不生效——关键卡在三点：

Db::transaction() 闭包方式为什么最安全？

它自动封装了 startTrans()、commit() 和 rollback()，异常一抛就回滚，不用手写 try-catch。

• 闭包内任何地方 throw \Exception 或发生未捕获错误，事务自动回滚
• 闭包执行完无异常，自动提交，代码干净不易漏
• 不支持跨连接事务（比如同时操作两个不同数据库），否则会报错或静默失败
• 示例：

  Db::transaction(function () { Db::table('order')->insert(['uid' => 100, 'status' => 'created']); Db::table('stock')->where('id', 1)->dec('num', 1); // 这里如果 stock 不足，dec 返回 false，但不会自动中断 // 必须手动判断并 throw，否则仍会 commit if (Db::table('stock')->where('id', 1)->value('num') < 0) { throw new \Exception('库存不足'); } });

手动事务 Db::startTrans() 容易在哪几步失效？

手动控制看似灵活，但每一步都可能断链：开启、判断、提交、回滚，缺一不可，且顺序不能乱。

• Db::startTrans() 必须在所有操作前调用，且只能调一次（重复调用不报错但无效）
• 每个 DB 操作后必须检查返回值或异常，delete()、update() 成功才返回影响行数，失败是 false 或抛异常
• 不能只靠 if ($a && $b) 判断，因为部分操作可能成功、部分 SQL 语法错误却没被 if 捕获（比如字段不存在）
• 必须在 catch 块里明确调 Db::rollback()，PHP 异常未被捕获时事务不会自动回滚
• 事务结束后不重置状态，后续请求若复用连接，可能意外卷入残留事务（尤其 FPM 模式下）

事务不回滚的常见底层原因有哪些？

表面代码没问题，但数据还是被改了——问题往往出在数据库层或连接配置上。

立即学习“PHP免费学习笔记（深入）”；

• 表引擎是 MyISAM：执行 SHOW CREATE TABLE user，确认输出含 ENGINE=InnoDB；老项目迁移常漏改字典表
• MySQL 连接开启了自动提交：Db::connect()->getPdo()->getAttribute(PDO::ATTR_AUTOCOMMIT) 应为 0，不是 1
• 混用了 InnoDB 和 MyISAM 表：哪怕只有一条 INSERT 到 MyISAM 表，这条语句立刻生效，rollback() 对它完全无效
• 事务中执行了 DDL（如 ALTER TABLE）、SELECT FOR UPDATE 外的锁操作，或调用了存储过程，可能隐式提交
• 超时被 MySQL 杀掉：innodb_lock_wait_timeout 默认 50 秒，长事务容易触发，但 PHP 层 catch 不到

高并发下事务要注意什么？

事务本身不解决并发冲突，反而可能放大问题，重点不在“怎么写”，而在“怎么设计”。

• 避免在事务里做 curl 请求、Redis 写入、日志记录等外部调用——它们拉长事务时间，增加锁竞争
• 更新顺序要一致：多个事务同时更新 user 和 order 表，必须固定先 update user 再 order，否则易死锁
• 尽量用 WHERE 精确匹配主键或唯一索引，避免全表扫描加锁；UPDATE ... WHERE status = 'pending' 可能锁住大量行
• ThinkPHP 的嵌套事务靠 savepoint 实现，但 savepoint 不是真正嵌套，外层 rollback 会连带清除所有 savepoint，别依赖它做复杂回滚逻辑
• 余额类场景建议加乐观锁：UPDATE account SET balance = balance - 100 WHERE id = 1 AND version = 5，失败时重试而非死等锁

真正难的不是写 Db::transaction()，而是确认每张表都是 InnoDB、每次操作都落在同一连接、每个失败分支都走到 rollback()——这些细节一漏，事务就形同虚设。