子查询慢多因相关子查询导致，外层每行触发内层重执行；应通过EXPLAIN识别SubPlan标记，优先改写为JOIN或EXISTS，并确保索引覆盖连接、过滤及排序字段。
子查询慢到卡住？先看是不是 correlated 子查询
绝大多数 SQL 嵌套查询性能差，根源在于写了 correlated subquery（相关子查询）——外层每查一行，内层就得重跑一次。比如 SELECT name FROM users WHERE id IN (SELECT user_id FROM orders WHERE status = 'paid') 看似简单，但若没索引或数据量大，实际可能触发全表扫描 × N 次。
实操建议：
- 用
EXPLAIN或EXPLAIN ANALYZE看执行计划，重点找SubPlan或dependent subquery这类标记 - 检查子查询里是否引用了外层表字段（如
WHERE orders.user_id = users.id），有就是相关子查询，优先改写 - MySQL 5.7+、PostgreSQL 12+ 对部分相关子查询做了自动去关联优化，但别依赖——它不总生效，尤其带
GROUP BY或LIMIT时
IN / EXISTS 性能差不多？别信，得看数据分布和索引
IN 和 EXISTS 表面等价，但引擎处理逻辑不同：IN 先算子查询结果集再哈希匹配，EXISTS 是对外层逐行做半连接探测。谁快，取决于内外表大小、索引覆盖、NULL 处理。
实操建议：
- 外层小、内层大且有索引 → 用
EXISTS（避免构造大临时结果集） - 外层大、内层小且结果确定无 NULL →
IN可能更快（现代优化器常转成哈希 semi-join） - 子查询含
NULL时，IN返回空结果（三值逻辑），EXISTS不受影响——这不是性能问题，是语义陷阱，先确认业务是否允许 NULL - 别手写
NOT IN (SELECT ...)，遇到 NULL 直接逻辑失效；换成NOT EXISTS或补IS NOT NULL条件
JOIN 改写不是无脑替换，要注意语义等价性
把子查询改成 JOIN 最常见，但容易翻车：去重、空值、多对一关系都会让结果变味。比如 SELECT u.name FROM users u WHERE u.id IN (SELECT user_id FROM logs) 改成 INNER JOIN 没问题；但要是原意是“查所有用户，标出有没有日志”，就得用 LEFT JOIN + COALESCE，否则漏数据。
实操建议：
- 子查询在
SELECT列中（如(SELECT COUNT(*) FROM comments c WHERE c.post_id = p.id)）→ 改成LEFT JOIN ... GROUP BY，注意加DISTINCT或聚合去重 - 子查询在
WHERE中作过滤 → 多数可转INNER JOIN或EXISTS，但需验证是否允许重复行（JOIN可能因一对多放大主表行数） - 涉及
ORDER BY+LIMIT的子查询（如分页取最新订单）→ 直接JOIN后排序会更慢，考虑用窗口函数或物化中间结果
索引建不对，JOIN 也白搭
改完 JOIN 还慢？大概率缺索引。子查询能走索引不代表 JOIN 也能——连接字段、过滤字段、排序字段的组合索引顺序很关键。比如 JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' ORDER BY o.created_at DESC，只在 user_id 上建索引没用。
实操建议：
- 连接字段必须有索引，且类型严格一致（
INTvsBIGINT隐式转换会丢索引） - 复合索引按“连接字段 + WHERE 字段 + ORDER BY 字段”顺序建，例如
(user_id, status, created_at) - PostgreSQL 注意
text字段默认不支持 B-tree 索引前缀，要用varchar(n)或加USING pg_trgm；MySQL 8.0+ 支持函数索引，可对JSON_EXTRACT结果建索引 - 定期用
pg_stat_all_indexes（PG）或sys.schema_unused_indexes（MySQL 8.0+）清理无效索引，它们会拖慢写入
最麻烦的不是不会改写，而是改完没验证结果是否一致——尤其涉及 NULL、重复、聚合时，务必比对改写前后返回的行数和内容。线上先用 SELECT COUNT(*) 和小范围 SELECT * LIMIT 100 对照，别直接上 UPDATE 或删索引。
