跨库查询与一致性

分库一旦完成，最先找上门的不是性能问题，而是「之前一条 SQL 能查完的数据，现在查不出来了」。跨库 join 被迫消失、事务不再全局有效、主键冲突、对账差异——这四件事是分库项目的「四只拦路虎」。本篇记录我们逐一驯服它们的过程，原则是：不追求强一致，追求可解释、可修复的最终一致。

章节 内容 你将获得
3.1 跨库 join 怎么绕开 绑定表、汇总表、应用层拼装三种武器
3.2 分布式事务 最终一致方案 本地消息表的完整设计
3.3 全局唯一 ID 订单号生成 雪花 ID 的位分配与时钟回拨
3.4 数据同步 分片间对账 对账脚本与差异修复流程

分库之后的一致性问题，本质上与微服务拆分后的问题同构：单体变多体，共识成本从「数据库送给你」变成「你自己造」。如果你读过 Go 实战：微服务 CPS，会对本篇的最终一致方案感到熟悉。

本篇的核心立场是务实的：不追求强一致，追求可解释、可修复。跨库事务的成本可以被算清（3.2 节有完整评估），全局唯一 ID 的位分配可以一次定终身（3.3 节），对账系统让一切差异可见（3.4 节）。读完本篇，你应该能在自己的系统里回答「这笔数据现在可能不一致多久、由谁修复、多久修好」这三个问题。

延伸阅读