IN (SELECT...)慢因数据库默认将其当作依赖子查询，导致外层每行都重执行内层查询；改用JOIN可大幅提升性能，且需确保关联字段有索引。
WHERE 中的 IN (SELECT ...) 为什么慢得离谱
因为多数数据库（尤其是 MySQL 5.7、SQL Server）默认把 IN (SELECT ...) 当作“依赖子查询”处理：外层每扫描一行，就重新执行一次内层查询。10 万行 × 10 万行 = 100 亿次扫描，不是卡顿，是直接超时。
真实场景里，SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'CN') 这种写法，在没开优化开关或没建对索引时，执行计划里 type 往往是 ALL 或 index，而不是 ref 或 eq_ref。
- MySQL 5.7 默认不展开该类子查询；升级到 8.0 后需显式开启
optimizer_switch='semijoin=on' - PostgreSQL / SQL Server 建议加
/*+ MATERIALIZE */或改用WITH强制物化中间结果 - Oracle 可用
/*+ UNNEST */提示让优化器把子查询拉平
把 IN 改成 JOIN 是最稳的落地动作
JOIN 不仅语义清晰，而且所有主流数据库都能高效利用索引和连接算法（如 Hash Join、Merge Join）。只要关联字段有索引，性能提升通常是数量级的。
比如把 WHERE customer_id IN (SELECT id FROM customers WHERE region = 'CN') 改成：
SELECT o.* FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE c.region = 'CN';
- 确保
customers.id和orders.customer_id都有索引（最好是主键或唯一索引） - 如果
customers表很小（ - 注意：若原逻辑是
LEFT JOIN语义（保留无匹配的 orders），改写后要补OR c.id IS NULL条件，不能只套 INNER
多层嵌套时，别让字段“一路拖到底”
像 SELECT * FROM (SELECT * FROM (SELECT * FROM t1 JOIN t2) t23) t34 WHERE ... 这种写法，每层都带全字段，IO 和内存压力指数增长。更糟的是，优化器未必能剪掉外层没用的字段——尤其当嵌套里用了视图或 CTE。
- 每一层只
SELECT下一层真正需要的字段：至少包括 JOIN 键、WHERE 过滤字段、ORDER BY 字段 - 给中间结果起明确别名，比如
(SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id) order_summary - 在 PostgreSQL 中用
EXPLAIN (ANALYZE, BUFFERS)观察Shared Hit Blocks是否异常高，判断是否因冗余字段拖慢缓冲区命中
标量子查询（SELECT 中的子查询）容易被忽略的坑
像 SELECT name, (SELECT AVG(salary) FROM employees) AS avg_sal FROM departments 看似无害，但如果子查询里有聚合 + 关联（比如 WHERE dept_id = d.id），就会退化成“相关子查询”，每行都算一遍平均值。
- 优先提取为
WITH公共表表达式，复用计算结果 - 确认子查询是否真的需要每行重算；如果是全局值（如全表平均），提前算好传参或存为变量
- MySQL 8.0+ 支持
LATERAL，可安全引用外层列，但要注意它仍可能触发多次执行，得看执行计划
真正难优化的从来不是语法嵌套本身，而是嵌套掩盖了数据分布失衡、索引缺失、统计信息过期这些底层问题。每次改写前，先看 EXPLAIN 或 EXPLAIN ANALYZE，否则再漂亮的 SQL 也跑不快。
