跨分片子查询拖垮吞吐量是因为子查询无法路由到单一节点，需在所有分片重复执行并汇总结果，导致网络、cpu、内存三重开销激增。
跨分片子查询为什么拖垮吞吐量
因为子查询无法被路由到单一节点，系统被迫对每个分片重复执行完整子查询逻辑，再把中间结果拉回协调节点做外层计算——这直接放大了网络、CPU 和内存三重开销。
子查询在分片环境下如何被错误执行
以 SELECT * FROM orders WHERE user_id IN (SELECT user_id FROM users WHERE city = 'Beijing') 为例：即使 orders 按 user_id 哈希分片，子查询 SELECT user_id FROM users WHERE city = 'Beijing' 仍无法定位分片（city 不是 users 表的分片键），导致：
- 子查询在所有
users分片上并行执行，每片都扫描局部数据 - 每个分片返回一批
user_id，协调节点需合并去重后才发给orders各分片 -
orders分片收到的是一个可能很大的IN列表，若未命中本地缓存索引，会触发全表扫描或大量随机 I/O - 整个链路无法 pipeline，必须等子查询全部完成才能启动外层查询
不同分片策略下子查询的性能差异
子查询是否可优化，取决于子查询条件字段是否与目标表的分片键对齐：
- 哈希分片表：仅当子查询能精确推导出分片键的等值条件（如
WHERE user_id = ?）时，才可能下推到单分片 - 范围分片表：若子查询含范围条件（如
WHERE created_at BETWEEN ? AND ?）且该字段是分片键，部分引擎可做分片裁剪，但多数仍需访问多个分片 - 目录分片（如 ShardingSphere 的
complex策略）：需额外元数据服务解析子查询逻辑，延迟更高，失败率也上升
实测中，一个含子查询的简单接口，在 8 分片集群上 QPS 从单库的 1200 降至 180，P99 延迟从 42ms 跳至 1.3s。
最容易被忽略的隐性瓶颈：结果集膨胀
子查询本身输出小，不代表它不危险。比如 SELECT order_id FROM orders WHERE status = 'paid' 在每个分片返回 1 万行，8 个分片就是 8 万行中间结果——这些数据要序列化、跨网络传输、反序列化、去重、构建哈希表，协调节点内存和 GC 压力陡增。更糟的是，如果外层查询还带 ORDER BY 或 LIMIT，排序必须在协调节点完成，无法下推。
真正卡住吞吐量的，往往不是磁盘或 CPU，而是协调节点的网络缓冲区打满、连接池耗尽、或 JVM 因大对象频繁 Full GC 暂停。
