跨节点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_cs vs utf8mb4_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

真正卡住的从来不是计算，是协调节点在等数据从十几个地方一块块拖回来——而这个过程几乎没法靠加机器缓解。