子查询缺失分片键会导致全库广播，使性能随分片数线性下降；函数或类型转换会切断路由；IN/EXISTS在分布式场景下难以优化，应改用分片对齐的JOIN或预热缓存。
因为子查询没带分片键，中间件无法路由，只能向所有物理节点广播执行——这不是“慢一点”，而是请求量直接乘以分片数。
子查询缺失分片键触发全库广播
分库中间件（如 ShardingSphere、TiDB）不推导逻辑关联，只做字面量路由。只要子查询的 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 倍，且随分片数线性增长
函数或类型转换让路由彻底失效
中间件靠静态解析 SQL 字面量做路由，一旦分片键被包装进函数或发生隐式转换，它就认不出这是分片字段了。
-
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')：函数使create_time索引失效，也切断路由上下文 - 正确写法是子查询只返回原始字段，过滤条件全部下推，例如
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')：每个分片都跑一遍子查询，再合并结果，容易触发内存溢出或网络截断 - 改用
JOIN并确保ON条件含分片键（如o.customer_id = c.id），且两张表按同一字段分片，才能保证关联落在单库内 - 若无法对齐分片策略，宁可冗余字段（比如把
region冗余进order表），也不要硬扛跨库JOIN
大结果集子查询必须异步预热或缓存
当子查询返回几千甚至上万行 ID（比如“昨日活跃用户”），再用于外层 IN，不仅路由崩，还极易导致中间件临时表撑爆内存或 TCP 包截断。
- 典型错误：
WHERE user_id IN (SELECT user_id FROM login_log WHERE dt = '2026-04-01')—— 子查询本身已跨节点扫表，结果再广播，双重放大 - 生产中应提前物化该结果到本地缓存或全局表，并加 TTL 控制新鲜度
- 若必须实时计算，至少加
LIMIT+ORDER BY RAND()控制输出规模，避免单次拉取失控
真正难处理的不是语法多嵌几层，而是子查询输出的 key 分布是否均匀、是否携带可路由的原始分片字段、以及中间件是否把它当“确定值”而非“表达式”来解析——这三个点漏掉任何一个，跨节点扫描就不可避免。
