thinkphp跨库事务失败的根本原因是mysql不支持真正的跨库原子事务，需手动管理多个独立连接的事务状态，而非依赖db::transaction()语法糖。
ThinkPHP 事务跨库失败的典型表现
直接在 Db::transaction() 里调用不同数据库连接的 insert() 或 update()，大概率只对默认库生效，其他库的操作会自动提交、不参与回滚。这是因为 ThinkPHP 的事务绑定在「连接实例」上，不是全局会话级事务 —— 多库意味着多个独立连接，彼此事务互不感知。
必须显式创建并复用多个数据库连接实例
不能依赖 Db::name() 这类静态调用，它每次可能取到新连接或默认连接。得提前用配置名初始化连接，并在整个事务块中重复使用同一个实例：
$db1 = Db::connect('mysql1');
$db2 = Db::connect('mysql2');
try {
$db1->startTrans();
$db2->startTrans();
$db1->table('user')->insert(['name' => 'a']);
$db2->table('log')->insert(['msg' => 'done']);
$db1->commit();
$db2->commit();
} catch (\Exception $e) {
$db1->rollback();
$db2->rollback();
throw $e;
}
-
Db::connect('mysql1')必须对应database.php中已定义的配置键，不能写错或临时传参数 - 两个
startTrans()要分开调，不能只调一次 - 两个
commit()/rollback()必须成对、顺序一致，否则可能留下半个事务
注意 MySQL 自身不支持跨库事务原子性
即使代码层面控制了多个连接的 commit/rollback，底层仍是两个独立的 XA 事务（除非你手动启用并配置 XA）。MySQL 默认隔离级别下，它们之间没有协调机制 —— 所以严格来说，这不是 ACID 意义上的“分布式事务”。常见折中方案：
- 业务层补偿：记录操作日志，失败后触发反向操作（如删刚插的 log）
- 用消息队列解耦：主库成功后发消息，由消费者异步写副库，配合本地事务表保证至少一次投递
- 升级为 Seata 或 ShardingSphere 等中间件（重量级，非 TP 原生支持）
TP6.1+ 的 Db::transaction() 不适用于多库
这个方法本质是语法糖，内部只对当前连接实例做 startTrans/commit/rollback。如果你传入闭包并试图在里面切换 Db::connect()，闭包执行时连接已脱离事务上下文：
// ❌ 错误示范：看似简洁，实际无效
Db::transaction(function () {
Db::connect('mysql1')->table('user')->insert([...]);
Db::connect('mysql2')->table('log')->insert([...]); // 此处事务已失效
});
真正可控的方式只有手动管理每个连接的事务状态，别图省事。
事务跨库这件事，表面是 TP 写法问题，根子在 MySQL 连接模型和事务边界。手动控制连接实例是最小侵入、最可验证的路径，但得接受它不是真正的“一荣俱荣”。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
