跨节点JOIN触发大量RemoteRequest，因为分布式SQL引擎默认不广播小表且不自动重分布数据；当JOIN字段非分片键时，执行器无法预判匹配行位置，只能让各节点跨节点拉取对方数据，形成多对多网络请求，导致带宽打满、协调节点CPU飙升、耗时随分片数线性增长。
跨节点JOIN为什么会触发大量RemoteRequest
因为分布式SQL引擎（如TiDB、Citus、StarRocks）默认不广播小表，也不自动重分布数据；当JOIN字段不是分片键时，执行器无法预判匹配行的物理位置，只能让每个节点主动拉取对方分片的数据。你看到EXPLAIN里出现RemoteRequest或Shuffle，基本就坐实了这个行为。
- 常见错误现象：
SHOW PROCESSLIST卡在Sending data，监控显示协调节点CPU和网络带宽同时打满 - 耗时随分片数线性增长——比如2分片查1秒，16分片就可能查8秒以上
- 同一SQL在单机MySQL秒出，在集群里跑十几秒，且
EXPLAIN ANALYZE里RemoteScan占70%+时间
分片键不一致=强制跨网络搬运数据
分片键决定数据落在哪个节点。只有当orders.user_id JOIN users.id中，两张表都按user_id分片，且JOIN条件是等值（=），优化器才敢把整个JOIN下推到单个节点执行。否则它必须保守地把两表数据都拉到协调节点合并。
- 容易被忽略的细节：
UPPER(u.name)、DATE_SUB(NOW(), INTERVAL 7 DAY)这类表达式会直接禁用分片亲和性判断 - 字符集/排序规则混用（如
utf8mb4_0900_as_csvsutf8mb4_general_ci）会导致“看起来能匹配，实际无法下推” - Citus要求JOIN字段必须是distribution column，TiDB要求
SHARD_ROW_ID_BITS设置一致才能保证哈希一致性
BROADCAST提示为什么有时更慢
/*+ BROADCAST(users) */确实能避免Shuffle，但它把users全量复制到每个计算节点内存里。如果这张表有500万行、每行平均200字节，16个节点就要额外占用16GB内存，极易触发OOM或频繁GC。
- 适用前提很苛刻：被广播表真实体积SELECT COUNT(*)和
AVG(LENGTH())算出来的实际内存占用） - 集群节点数≤8，且各节点剩余内存>2GB
- 该表极少更新——否则每次变更都要重新广播，同步延迟会破坏JOIN结果一致性
- 注意语法差异：
BROADCAST在Greenplum中叫DISTRIBUTED REPLICATED，StarRocks需配合SET enable_broadcast_join = true，别套用错
统计信息过期会让优化器彻底误判
EXPLAIN看起来没变，但性能差十倍？大概率是统计信息过期导致优化器误判数据局部性。它以为某张表很小可以广播，结果实际是2GB；或者以为JOIN能下推，结果全量拉取。
- 检查方式：
SHOW STATS_META（TiDB）、SELECT * FROM pg_stats（Citus） - 强制刷新：
ANALYZE TABLE orders，尤其在大批量写入后必须做 - 某些引擎（如Doris）需手动开启
enable_nereids_planner = true才能识别分片亲和性，否则一律走ShuffleJoin
真正卡住的从来不是计算，是协调节点在等数据从十几个地方一块块拖回来——而这个过程几乎没法靠加机器缓解。
