子查询未带分片键会导致全库广播，因中间件仅做静态解析、无法推导关联逻辑；即使小表也会在每个分片重复执行，再拼in列表，耗时随分片数线性增长。
子查询没带分片键 → 全库广播是默认 fallback
分布式数据库中间件（如 ShardingSphere、TiDB、MyCat）不推导逻辑关联，只做静态 SQL 解析。只要子查询的 WHERE 条件里没出现分片键（比如 user_id、order_id），就无法确定该查哪几个物理节点，只能向全部分片广播执行。
常见错误写法：SELECT * FROM order WHERE user_id IN (SELECT user_id FROM vip_user WHERE level > 5) —— 外层有 user_id，但子查询完全没提分片字段，中间件看不到路由线索。
哪怕 vip_user 是百行小表，也会在每个分片上重复执行一遍子查询，再把结果拼成超长 IN 列表传给外层。8 分片环境下，耗时通常是单库的 6–10 倍，且随分片数线性增长。
函数或类型转换让分片路由彻底失效
中间件靠字面量匹配识别分片键。一旦你对分片字段套了函数或发生隐式转换，它就认不出这是分片字段了。
典型踩坑点：
-
WHERE user_id IN (SELECT CAST(id AS CHAR) FROM temp_ids)——CAST导致类型不匹配，路由失败 -
WHERE user_id IN (SELECT id FROM users WHERE DATE(create_time) = '2026-04-01')——DATE()切断路由上下文，也使索引失效
正确写法是子查询只返回原始字段，过滤条件全部下推：SELECT id FROM users WHERE status = 'active' AND id BETWEEN 1000 AND 2000。
IN/EXISTS 在分布式场景下基本不可优化
大多数分库中间件不支持子查询结果下推、semi-join 或物化。它们看到 IN 就拆成多次独立查询，而不是一次定位+批量拉取。
例如：WHERE customer_id IN (SELECT id FROM customer WHERE region = 'CN')，每个分片都跑一遍子查询，再把结果合并成一个可能超长的 IN 列表——容易触发中间件内存溢出或网络截断。
更稳妥的替代方案：
- 改用
JOIN，且确保ON条件含分片键（如o.customer_id = c.id），两张表按同一字段分片 - 若无法对齐分片策略，宁可冗余字段（比如把
region冗余进order表），也不要硬扛跨库JOIN
大结果集子查询必须异步预热或缓存
当子查询返回几千甚至上万行 ID（比如“昨日活跃用户”），再用于外层 IN，不仅路由崩，还极易导致中间件临时表撑爆内存或 TCP 包截断。
这类场景不能靠改写 SQL 解决，必须前置处理：
- 用应用层定时任务预查并缓存 ID 列表（如 Redis 存 Set 或 Sorted Set）
- 在中间件层启用异步预热机制（如 ShardingSphere 的
sql-route-cache+ 异步加载） - 对高频固定范围，直接建宽表或物化视图（如
daily_active_user_20260927）
最危险的是把“子查询慢”当成 SQL 写法问题去调优，而忽略了它本质是数据物理分布与查询逻辑错配——这个错配点，往往在上线前的压测阶段才暴露出来。
