跨库JOIN慢的核心是数据物理分离导致90%时间耗在数据搬运而非计算；优化前提为JOIN字段严格对齐分片键，需检查表结构、禁用函数、验证索引与统计信息，并依场景选用下推、归并连接或物化视图。
跨库 JOIN 慢，核心问题不是 SQL 写得不对，而是数据物理上不在一起——查询要等网络传、等节点拉、等重分布，90% 时间花在搬数据上，不是算数据上。
确认 JOIN 字段是否为相同分片键
这是所有优化的前提，不满足就别谈“快”。分布式数据库（如 TiDB、Citus、Doris）只有当两表的 JOIN 条件字段与各自的分片键完全一致、且是等值比较时，才可能把整个 JOIN 下推到单个节点执行。
- 检查命令：
SHOW CREATE TABLE orders和SHOW CREATE TABLE users，确认shard_key字段名和类型是否严格一致（比如都是user_id BIGINT，而非一个用id、一个用uid） - 禁止混用函数：哪怕只是
ON o.user_id = u.id + 0，也会让优化器放弃亲和性判断 - TiDB 中可用
EXPLAIN FORMAT = 'VERBOSE'查看执行计划里是否有TableReader直接下推；若看到RemoteRequest或Exchange算子，说明已跨节点
避免小表广播（BROADCAST）滥用
很多人一看到“小表”就加 /*+ BROADCAST(t2) */，结果更慢——广播不是免费午餐，它会把整张表副本塞进每个节点内存，协调节点还要维护元数据一致性。
- “小”必须满足两个条件：
单副本数据量 < 10MB且更新频率 < 每小时 1 次；否则广播失效后反复重加载，反而拖垮 coordinator - Citus 需显式标记本地表：
SELECT citus_set_local_table_colocation('dim_status', 0, 'dim_region')，否则即使表只存一份，也可能被误判为分布表而触发 shuffle - 若右表是空或几乎为空（如 LEFT JOIN 的维度表刚清空），仍会全分片扫描确认匹配存在性——此时不如改用
WHERE EXISTS+ 子查询下推
强制归并连接（MERGE JOIN）代替默认 shuffle
当无法对齐分片键时，哈希连接不可用，嵌套循环又太伤，归并连接是折中选择：要求两表在 JOIN 字段上都有有序索引，按序流式合并，避免全量广播。
- TiDB 使用
/*+ TIDB_SMJ(orders, users) */强制走 sort-merge join；注意需确保orders.user_id和users.id均有索引且统计信息准确（ANALYZE TABLE orders） - CockroachDB 对应 HINT 是
/*+ MERGEJOIN */，但前提是两表都按 JOIN 字段升序排列，否则会先排序再 merge，开销翻倍 - 若执行计划里出现
Using join buffer (hash join)，说明索引缺失或类型不匹配（如orders.user_id是BIGINT，users.id是INT），隐式转换导致索引失效
用物化视图或预聚合替代实时 JOIN
如果某类 JOIN 模式固定、下游查询高频（如“订单+用户城市+商品类目”每日被查上百次），硬扛实时分布 JOIN 不如提前固化逻辑。
- TiDB 暂不支持自动刷新物化视图，但可用
CREATE TABLE order_user_agg AS SELECT ... FROM orders JOIN users ... GROUP BY ...+ 定时任务重建 - StarRocks 支持
CREATE MATERIALIZED VIEW mv_order_user AS SELECT o.order_id, u.city, u.level FROM orders o JOIN users u ON o.user_id = u.id，并启用enable_nereids_planner = true让查询自动路由到 MV - 警惕宽表陷阱：若
users表有 48 个描述字段，但每次只用city和level，预聚合时务必只选必要列，否则中间结果膨胀比 JOIN 还伤
最容易被忽略的一点：统计信息过期。你改了 JOIN 条件、加了索引、甚至调了分片策略，但 EXPLAIN 看起来没变，性能却差十倍——大概率是 ANALYZE TABLE 没跑，优化器还在按旧分布做决策。分布式环境里，数据分布不准，比 SQL 写错更致命。
