跨分片join触发大量remoterequest，是因为分布式sql引擎默认不广播小表且不自动重分布数据；当join字段非分片键时，执行器只能让各节点跨节点拉取对方数据，形成多对多网络请求，导致网络带宽打满、协调节点cpu飙升、耗时随分片数线性增长。
跨分片JOIN为什么触发大量RemoteRequest
因为大多数分布式SQL引擎（如TiDB、Citus、OceanBase）默认不广播小表，也不自动重分布数据——当JOIN字段不是分片键时，执行器只能让每个节点各自拉取对方分片的数据，形成多对多的跨节点请求。你看到EXPLAIN里出现RemoteRequest或Shuffle，基本就坐实了这个行为。
常见错误现象包括：
-
EXPLAIN显示MergeJoin或HashJoin，但实际执行时网络带宽打满、协调节点CPU飙升 - 查询耗时随分片数线性增长（比如从2分片到16分片，耗时翻8倍）
- 同一SQL在单机MySQL秒出，在集群里跑10秒以上且
SHOW PROCESSLIST卡在Sending data
为什么分片键不一致就一定走网络传输
分片键决定数据物理位置。只有当orders.user_id JOIN users.id中，orders和users都按user_id分片，且JOIN条件是等值（=），优化器才敢把整个JOIN下推到单个节点执行。否则，它无法预判哪条orders记录该匹配哪个users分片，只能保守地把两表数据都拉到协调节点合并。
容易被忽略的细节：
- 大小写、空格、字符集差异（如
utf8mb4_0900_as_csvsutf8mb4_general_ci）会导致“看起来一样，实则无法下推” - JOIN字段带函数（如
UPPER(u.name)）或表达式（如o.created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)）会直接禁用分片亲和性判断 - Citus要求JOIN字段必须是分布列（distribution column），且类型完全一致；TiDB要求
SHARD_ROW_ID_BITS设置相同才能保证哈希一致性
BROADCAST提示为什么有时更慢
加/*+ BROADCAST(users) */确实能避免Shuffle，但它把users全量复制到每个计算节点内存里。如果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看起来没变，但性能差十倍？大概率是统计信息陈旧。优化器依赖ANALYZE TABLE产出的行数、NDV（不同值数量）、直方图来估算是否值得广播或重分布。如果某张表刚导入2亿新数据却没ANALYZE，优化器仍按10万行估算，就会错误选择Nested Loop而非Broadcast。
实操检查项：
- TiDB：查
SHOW STATS_META WHERE table_name = 'orders'，看modify_count是否远大于count的10% - Citus：连到coordinator执行
SELECT * FROM pg_stats WHERE tablename = 'users'，确认n_distinct非-1 - 强制刷新：TiDB用
ANALYZE TABLE orders，Citus用ANALYZE users，不要依赖自动收集（默认关闭或间隔太长）
真正难缠的点不在语法或配置，而在于：数据分布特征（比如user_id倾斜率达90%）和查询模式（比如固定查TOP 10大客户）之间存在隐式耦合——这种问题，EXPLAIN看不出，监控图表也难以归因，得靠SELECT /*+ HASH_AGG() */ COUNT(DISTINCT user_id)这类探针SQL手动验证。
