ThinkPHP跨库查询不能用join()因表名被强制加前缀，需用原生SQL或临时表；跨库事务不共享，须用Saga模式+幂等日志实现最终一致。
ThinkPHP跨库查询为什么不能用join()方法
因为 Db::table()->join() 会强制给所有表名加上当前连接的 prefix，而跨库 JOIN 必须显式写成 db1.user 和 db2.order 这种全限定名格式。Query 构建器根本不提供控制左侧表库名的入口，一调就报 Base table or view not found。
可行路径只有两条：
- 改用
Db::query()执行原生 SQL，手动拼全库名，例如SELECT u.name, o.amount FROM db1.user u JOIN db2.order o ON u.id = o.user_id - 用临时表折中：先
CREATE TEMPORARY TABLE tmp_user AS SELECT * FROM db1.user，再跟db2.order关联——注意临时表名不能带库前缀，且每次用完得主动DROP TEMPORARY TABLE - 权限别漏：执行跨库 SQL 的 MySQL 账号，必须同时拥有
db1和db2的SELECT权限，否则连原生语句都过不去
Db::connect('db2')->startTrans() 和默认连接事务完全隔离
每次调用 Db::connect() 都新建一个独立的 PDO 实例，事务状态不共享。你在 db1 上 startTrans()，再在 db2 上也 startTrans()，这其实是两个互不感知的事务。任一连接 commit() 或 rollback()，对另一个毫无影响。
典型翻车现场：
立即学习“PHP免费学习笔记（深入）”；
- 代码里套了个
try/catch，两边都commit()，结果db1写进去了，db2因网络超时失败，程序却返回“成功” - 误以为
Db::transaction()能包住多库操作——它只作用于当前连接，换库就得换连接，事务上下文就断了 - MySQL 8.0+ 默认关闭
xa_support，TP 更没封装xaCommit()等接口，硬上 XA 就是给自己埋定时任务
跨库操作必须放弃原子性，用 Saga + 幂等日志落地
真正的生产级方案不是“怎么让 TP 支持跨库事务”，而是承认单次操作无法强一致，转而用可追踪、可补偿的流程兜底。
核心三件事必须一起做：
- 主库（如
order_db）写入成功后，立刻在同一事务内往本地saga_log表插入一条记录，含order_sn、步骤名（create_order）、状态（pending） - 再调
user_db扣积分，成功则更新saga_log状态为done；失败则记failed+ 错误详情 - 后台 CLI 脚本定时扫
saga_log中failed记录，按反向顺序调补偿接口（如cancel_order(order_sn)），且该接口必须先查日志确认未执行过
saga_log 表必须和主业务表在同一个库、同一事务写入，否则日志丢了，补偿就彻底失联。
模型指定 $connection 不等于支持跨库事务
给 UserModel 设 $connection = 'db1'，给 OrderModel 设 $connection = 'db2'，这只是让两个模型走不同连接，和事务无关。你用 UserModel::startTrans()，只锁 db1；OrderModel::startTrans() 是另一把锁，根本不在一个维度上。
如果真要协调多库动作，唯一可控的起点是：
- 所有涉及的数据库配置必须定义在
connections数组里，不能靠 DSN 字符串临时拼接 - 任何跨库写入，控制器层只负责触发第一步（写主库 + 写日志），后续全部交由异步任务或消息队列驱动
- 别在 Web 请求里直接
Db::connect('db2')->insert()—— 网络抖动、超时、PDO 连接复用都会让状态不可预测
最易被忽略的一点：补偿逻辑不能引入新外部依赖。比如扣积分失败后，补偿接口再去调一次微信支付回调，那微信挂了，整个链路就卡死。补偿本身必须是本地、幂等、无外部 IO 的。
