分布式 JOIN 快的前提是两表按相同分片键亲和分布，否则必跨节点导致性能断崖；需确保分片键一致、JOIN 条件严格匹配、统计信息准确，并结合元数据验证实际数据分布。
JOIN 在分布式数据库中能快，前提是数据“住得近”——即参与 JOIN 的两表记录物理上位于同一节点。这叫亲和性分布（affinity distribution）。做不到这点，JOIN 就大概率退化为跨节点拉取、广播或 shuffle，性能断崖式下跌。
确认两表是否按相同分片键（shard key）分布
这是所有优化的前提，不是可选项，是硬门槛。 分布式数据库（如 TiDB、Citus、Doris）只有在JOIN 条件字段与两表的分片键完全一致且为等值时，才可能将整个 JOIN 下推到单个节点执行。
-
常见错误现象：
-
EXPLAIN显示HashJoin或MergeJoin下挂RemoteRequest - 查询耗时随分片数线性增长，
CPU和网卡打满 -
SHOW STATS_META显示统计信息陈旧（尤其大批量写入后未ANALYZE TABLE）
-
-
实操建议：
- 检查建表语句：确认
orders和users是否都按user_id分片（例如 Citus 中DISTRIBUTED BY (user_id)） -
JOIN条件必须严格写成ON orders.user_id = users.user_id，不能是ON orders.uid = users.id（列名不一致 → 无法识别亲和性） - 避免函数包装：
ON YEAR(order_date) = YEAR(user_reg_date)会破坏分片键匹配，直接失效
- 检查建表语句：确认
小表要不要广播？先看内存和副本放大风险
BROADCAST 是绕过亲和性限制的常用手段，但代价明确。
-
使用场景：
- 右表行数 < 10 万且稳定、无高频更新
- 查询频次高、延迟敏感，且集群内存充足
-
实操建议：
- TiDB 中加 hint：
/<em>+ BROADCAST(users) </em>/ SELECT ... FROM orders JOIN users ... - Doris 中需开启
enable_nereids_planner=true才能触发广播优化，否则默认走ShuffleJoin - 广播后，每个节点内存都会加载一份
users全量副本 —— 若有 32 个节点，100MB 的小表实际占用 3.2GB 内存 - 不要对日增百万行的维度表（如
region_config）盲目广播，容易 OOM
- TiDB 中加 hint：
LEFT JOIN 右表为空时为什么更慢？别跳过扫描逻辑
空右表 ≠ 不扫描右表。分布式环境下，LEFT JOIN 仍需验证“左表每条记录在右表是否存在匹配”，这个判断本身就要触达右表所有分片。
-
常见错误认知：
- “右表没数据，查询应该秒出” → 实际可能扫遍全部分片节点
- 忽略右表缺失索引：即使只查 1 行，若右表没在
JOIN字段建索引，仍会全分片扫描
-
实操建议：
- 对右表的
JOIN字段强制建索引（如CREATE INDEX idx_user_id ON users(user_id)） - 若业务确定右表常为空，考虑改用
EXISTS子查询替代：SELECT * FROM orders WHERE EXISTS (SELECT 1 FROM users WHERE users.user_id = orders.user_id)，部分引擎能更好下推 - TiDB 6.0+ 支持
LEFT HASH JOIN的 early-exit 优化，但需确保统计信息准确，否则优化器可能忽略
- 对右表的
EXPLAIN 看不出跨节点传输？得结合数据分布元信息交叉验证
EXPLAIN 输出的是计划结构，不是真实数据流。真正决定是否跨节点的是“数据在哪”+“怎么连”的组合判断，这个决策发生在执行器调度阶段。
-
容易被忽略的点：
-
EXPLAIN FORMAT = 'VERBOSE'在 TiDB 中可显示task类型（copvsroot），但依然不体现远程请求次数 - Citus 中需查
pg_dist_partition确认表分布策略，再用SELECT * FROM citus_shards_for_table('users')查实际分片位置 - Doris 的
EXPLAIN中若出现ExchangeNode，基本等于已确认要 shuffle
-
-
实操建议：
- 执行前先跑：
SELECT count(*) FROM orders, users WHERE orders.user_id = users.user_id，观察实际耗时与单节点查询的倍数关系（2 倍以内较健康，5 倍以上大概率已跨节点） - 开启慢查询日志并抓取
Plan和ExecStats，重点关注RemoteRequestCount和BytesSent字段
- 执行前先跑：
亲和性不是配置开关，是表结构、查询写法、统计信息三者咬合的结果。少一个环节，JOIN 就可能从毫秒掉到秒级——而且这种掉坑往往无声无息，只在压测或上线后暴露。
