Hyperf 多数据库定时任务中事务无法跨库生效，因 MySQL 不支持跨库事务；应采用单库事务+应用层补偿机制，如先主库后辅库、幂等快照表、消息队列最终一致性。
Hyperf 定时任务中涉及多数据库连接时，事务无法跨库自动生效——MySQL 本身不支持跨库事务（除非使用 XA 协议，但 Hyperf 默认未集成且生产环境极少启用）。因此，“多数据库连接下的事务一致性”本质上不是靠数据库事务兜底，而是靠应用层协同控制 + 补偿机制来保障。
明确事务边界：单库事务是唯一可靠选项
Hyperf 的 DB::beginTransaction() 等操作只作用于当前连接的数据库实例。即使你配置了多个数据库连接（如 'mysql1' 和 'mysql2'），调用 DB::connection('mysql1')->beginTransaction() 不会影响 mysql2 的状态。
- 事务只能在单个 PDO 连接内保证 ACID，跨连接即跨物理连接，无原子性可言
- Hyperf 的连接池、协程上下文均按连接名隔离，不存在“全局事务句柄”
- 不要尝试用
DB::transaction()包裹跨库操作——它只会对默认连接生效，其余连接的操作游离在事务外
跨库一致性的可行方案
当定时任务需同时写 A 库和 B 库（例如更新订单库 + 扣减库存库），推荐以下分层策略：
- 先写主库，再写辅库：把核心状态变更放在第一个库（如订单创建），成功后再操作第二个库（如库存扣减）；失败则回滚主库，并记录失败日志供人工或补偿任务处理
-
引入幂等+补偿任务：为每个跨库操作生成唯一业务 ID（如
task_id + timestamp），写入一张本地「事务快照表」；若辅库写入失败，由另一个定时任务扫描该表，重试或告警 - 用消息队列解耦：主库提交后发消息（如 Kafka/RabbitMQ），由独立消费者处理辅库操作；配合消费确认 + 死信队列，实现最终一致性
- 避免强一致性场景：评估业务是否真的需要“同时成功/失败”。多数计费、对账类场景可接受秒级延迟，用异步+校验更健壮
定时任务中安全使用多库事务的实操要点
若仍需在单次任务中协调多个库，注意这些关键细节：
- 显式指定连接：
DB::connection('mysql1')->table(...)->insert(...)，避免误用默认连接 - 各库分别开启/提交/回滚：
DB::connection('mysql1')->beginTransaction()和DB::connection('mysql2')->beginTransaction()必须独立管理 - 异常时逐个回滚：
catch块中先回滚已开启事务的连接，再抛出异常中断任务 - 禁用连接复用干扰：确保定时任务运行时未开启连接池共享（尤其与 async-queue 共用 Redis 连接池时，避免锁竞争影响 DB 连接获取）
替代思路：用分布式事务中间件（谨慎评估）
极少数强一致要求场景（如金融级资金划转），可考虑引入 Seata 或基于 TCC 模式的自研方案，但需额外部署组件、增加运维复杂度，且 Hyperf 生态原生支持有限。不建议在普通定时任务中引入。
