分库分表后无法直接跨库join，因mysql不支持跨物理实例关联；需采用应用层join、中间件代理或冗余宽表等方案，核心在于权衡实时性与一致性。
分库分表后 JOIN 无法直接跨库执行
MySQL（以及大多数主流关系型数据库）不支持跨物理实例的 JOIN。一旦表被拆到不同数据库（如 order_db_01、order_db_02），哪怕逻辑上是同一张表的分片，原生 SQL 的 JOIN user ON order.user_id = user.id 就会报错：Unknown database 'user_db' 或连接拒绝——因为每个数据库连接只指向一个物理实例。
这不是语法问题，而是架构层面的隔离。分库分表后，数据库连接池、事务边界、主从路由都绑定在单库实例上。
用应用层 JOIN 替代 SQL 层 JOIN
最常用、最可控的方式：把原本一次 SQL 完成的关联，拆成多次查询，在代码里组合数据。
- 先查主表分片数据（比如从
order_db_01.order_01查出 10 条订单） - 提取所有
user_id，去用户库（可能是单库，也可能是按user_id分片的user_db_00～user_db_03）批量查用户信息 - 用
Map<user_id user></user_id>做哈希关联，拼装结果
注意点：
- 避免 N+1 查询：一定要用
IN批量查用户，而不是循环单条查 - 注意
IN参数上限（MySQL 默认 65535 个，但实际建议控制在 1000 以内，防长事务和网络抖动） - 如果用户表也分库，需根据
user_id路由到对应库再查，不能盲目发往所有库
用中间件（如 ShardingSphere、MyCat）做透明 JOIN
这类组件会在客户端或代理层解析 SQL，自动拆解、路由、聚合结果。例如你写 SELECT * FROM order o JOIN user u ON o.user_id = u.id，中间件会：
- 识别
order和user的分片规则（比如都按user_id取模） - 若分片键对齐（即
order和user在相同user_id下落在同库同表），则下推到单库执行JOIN - 否则，降级为应用层
JOIN或广播查询（性能差，慎用）
关键限制：
- 仅支持简单等值
JOIN，不支持LEFT JOIN、子查询嵌套、非分片键关联 - 跨库
ORDER BY/LIMIT需归并排序，内存和延迟明显上升 - ShardingSphere 5.x 后默认关闭分布式
JOIN，需显式配置sql-show: true和query-with-cipher-column: false等开关
提前冗余字段或构建宽表（牺牲写一致性换读性能）
当关联查询频繁且实时性要求不高时，反范式化更实际。比如在订单表中冗余 user_name、user_phone，或单独建一张 order_user_detail 宽表，通过异步任务（如 Canal + Kafka + Flink）同步更新。
好处是读完全走单表，无任何 JOIN 开销；代价是：
- 写链路变长，用户改名后订单展示可能延迟几秒到几分钟
- 宽表字段多、更新频繁时，binlog 解析和下游消费容易成为瓶颈
- 历史数据迁移复杂，尤其涉及分页重刷场景
真正难的不是选哪种方案，而是判断「哪些 JOIN 必须实时强一致」、「哪些可以接受最终一致」——这个权衡一旦做错，后期重构成本远高于初期多写几行关联代码。
