JOIN在分片表上慢是因为默认不广播小表，而是跨节点拉取数据，导致网络请求激增、重复扫描和中间结果膨胀；需确保JOIN字段为相同分片键才能单节点执行。
JOIN 在分片表上为什么慢得像卡住？
因为大多数分布式数据库（比如 TiDB、OceanBase、Citus）默认不会把 JOIN 拆成「先广播小表、再本地连接」，而是让每个节点各自拉取所需数据——如果 JOIN 涉及的表分布在不同节点，就会触发大量跨节点网络请求，甚至出现重复扫描和中间结果膨胀。
常见错误现象：EXPLAIN 显示 HashJoin 或 MergeJoin 下面跟着 RemoteRequest；查询耗时随分片数线性上涨；CPU 和网络带宽同时打满。
- 优先确认 JOIN 字段是否是分片键（shard key）：只有等值 JOIN 且字段与分片键完全一致时，才可能下推到单节点执行
- 避免用非分片键字段做 JOIN，例如
orders.user_id JOIN users.id，而users表按region分片 —— 这必然触发广播或 shuffle - 小表（BROADCAST（TiDB 用
/*+ BROADCAST(t2) */），但注意广播后每个节点都会存一份副本，内存压力陡增
为什么 EXPLAIN 看不出数据要跨节点传输？
EXPLAIN 输出只反映执行计划结构，不体现实际数据流向。真正决定是否跨节点的是「数据分布信息」+「JOIN 条件」的组合判断，而这个决策在优化器生成计划后、执行器真正调度前才最终确定。
使用场景：你改了 JOIN 条件，EXPLAIN 看起来没变，但实际性能差十倍——大概率是统计信息过期，导致优化器误判数据局部性。
- 检查表统计信息是否更新：
SHOW STATS_META（TiDB）或SELECT * FROM pg_stats（Citus） - 强制刷新统计：
ANALYZE TABLE orders，尤其在大批量写入后 - 某些引擎（如 Doris）需手动开启
enable_nereids_planner=true才能识别分片亲和性，否则一律走 ShuffleJoin
LEFT JOIN 右表为空时，为什么反而更慢？
空右表 ≠ 不查右表。分布式环境下，LEFT JOIN 仍需确认「每条左表记录在右表是否存在匹配」，这就要求右表至少被扫描一次。如果右表是大分片表且无合适索引，就会触发全分片扫描 + 跨节点聚合。
参数差异：MySQL 单机 LEFT JOIN 可能用 Index Nested Loop 快速探查，但分布式版往往退化为 Broadcast/HashJoin，代价模型完全不同。
- 确保右表 JOIN 字段有全局唯一索引（不是普通索引），否则无法定位到具体分片
- 若业务允许，把
LEFT JOIN ... ON ... WHERE t2.id IS NULL改成NOT EXISTS子查询，部分引擎（如 TiDB v7.5+）能更好下推谓词 - 警惕隐式类型转换：比如
orders.user_id (BIGINT)JOINusers.id (VARCHAR)，会导致索引失效，所有分片都参与扫描
跨节点 JOIN 出现 “timeout” 或 “too many connections” 错误
这不是 SQL 写错了，是执行器在协调多个节点时，某个环节超时或资源耗尽。典型如：一个 JOIN 需从 32 个节点各拉取 1GB 数据，在汇总节点解压+哈希建表，瞬间吃光内存或连接池。
性能影响：这类错误往往伴随 Region is unavailable（TiDB）、Failed to fetch data from remote node（Doris）或 PostgreSQL 的 canceling statement due to user request。
- 调大执行超时：
SET tidb_distsql_scan_concurrency = 15（降低并发但减少单次压力） - 限制中间结果大小：
SET tidb_max_chunk_size = 64，避免大 batch 堵塞网络缓冲区 - 检查目标节点连接池：Citus 要调
max_connections和citus.max_adaptive_executor_pool_size，否则 coordinator 会拒绝新请求
最容易被忽略的一点：分片键选择本身决定了 JOIN 成本天花板。哪怕调优所有参数，只要两个表的分片键不一致、又必须高频 JOIN，就永远绕不开网络 shuffle。这时候该考虑冗余字段、异步物化、或者换用支持 colocation 的引擎（如 Greenplum 的 DISTRIBUTED BY 对齐）。
