ThinkPHP多数据库事务失败的根本原因是事务无法跨连接生效，Db::transaction()仅作用于当前PDO连接实例；混用主库与从库连接会导致回滚失效，必须统一使用单连接执行带库名前缀的SQL或采用本地事务+异步补偿方案。
ThinkPHP 多数据库事务处理失败，根本原因不是“不支持”，而是事务本身无法跨连接生效——Db::transaction() 只作用于当前连接实例，你调用 Db::connect('slave') 或 db('log') 就等于开了新连接，事务自然失效。
为什么 Db::transaction() 对多库操作无效
事务是 MySQL 连接级特性，不是数据库级或框架级抽象。ThinkPHP 的 Db::transaction() 底层调用的是 PDO 的 beginTransaction()，它只对当前 PDO 实例起作用。一旦你在事务闭包里混用不同连接（比如主库写订单、从库写日志），那两个操作根本不在同一个事务上下文中。
- 错误现象：主库插入成功，从库日志没写，但也没报错；或反过来，回滚后主库数据还在
- 典型误用：
Db::transaction(function () { Db::name('order')->insert([...]); db('log')->table('op_log')->insert([...]); }); - 本质问题：
db('log')创建了独立连接，ROLLBACK指令只发给了主连接，对日志库连接毫无影响
多库写入必须用单连接 + 跨库 SQL
真正可行的方案是放弃“多连接事务”，改用一个连接执行含数据库前缀的原生 SQL，确保所有操作落在同一连接上。前提是 MySQL 用户有跨库权限，且表结构兼容。
- 正确做法：统一用主连接，SQL 中显式指定库名，例如
INSERT INTO `shop_order`.`order` (...) VALUES (...)和INSERT INTO `shop_log`.`op_log` (...) VALUES (...) - 避免模型调用：
User::create()会绑定默认库，不能跨库；必须用Db::execute()或Db::query() - 注意字符集和引擎一致性：两个库的同名表若一个是 MyISAM、一个是 InnoDB，哪怕走同一连接，
ROLLBACK也只对 InnoDB 表生效
替代方案：本地事务 + 异步补偿
当业务强要求“订单+日志”原子性，又无法合并到单库时，应放弃数据库事务，改用“本地事务保主数据 + 消息队列补日志”的最终一致性模式。
立即学习“PHP免费学习笔记（深入）”；
- 步骤：在主库事务内写订单，并插入一条
task_queue记录（状态 pending）；commit 后，由 CLI 进程消费该任务，写日志库；失败则重试或告警 - 禁用场景：不要在事务闭包里调用
curl、file_put_contents或发短信——这些操作不可回滚，且可能阻塞连接 - 关键点：
task_queue表必须与主业务表同库同引擎，确保插入和订单写入能被同一ROLLBACK覆盖
读写分离下事务必须强制走主库
即使你没显式调用从库，ThinkPHP 在读写分离配置下，Db::name('user')->select() 默认走从库——这会导致事务中查不到刚插入的数据，进而引发逻辑错判。
- 事务内所有查询都必须强制主库：
Db::master()->name('user')->select()，否则SELECT不在事务快照里 - 别依赖
lastInsertId()后立刻select，因为从库延迟可能导致查不到；要么用主库查，要么用自增 ID 直接构造条件 - 检查配置项
'read_master' => true是否开启——它会让读操作在事务中自动切回主库，但仅限于模型/Query 构建器，不适用于db('xxx')助手函数
多库事务本质上是个伪需求。真正要守住的不是“同时成功”，而是“可追溯、可补偿、不丢数据”。把事务边界收窄到单连接，把跨库动作移出事务，比硬扛 MySQL 局限更可靠。尤其要注意 db('xxx') 和 Db::connect() 这类看似无害的操作，它们才是悄悄断开事务链的元凶。
