相关子查询因语义要求必须逐行执行：只要引用外层列（如o.user_id = u.id），数据库就无法预计算，只能为外层每行代入新值重算内层逻辑，10万行即执行10万次；EXPLAIN中出现DEPENDENT SUBQUERY且rows接近外层行数即可确认。
相关子查询为什么总在逐行循环执行
只要子查询里引用了外层表的列（比如 o.user_id = u.id），它就是相关子查询。数据库无法提前算出结果，只能等外层某一行进来后，代入新值再跑一遍内层逻辑——10 万行主表，就真执行 10 万次子查询。这不是配置问题，是语义决定的。
常见错误现象：EXPLAIN 中看到 select_type = DEPENDENT SUBQUERY，且 rows 列数值和外层扫描行数接近，基本就能确认是它在拖慢。
用 JOIN 替代 WHERE + 相关子查询的实操条件
不是所有相关子查询都能直接改写为 JOIN，但满足以下条件时，安全、高效、可验证：
- 子查询只用于过滤（如
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)）或取单值（如SELECT (SELECT name FROM dept d WHERE d.id = u.dept_id)） - 关联字段已有索引（比如
orders.user_id和users.id都有索引） - JOIN 后不引入重复行（必要时加
DISTINCT或用LEFT JOIN ... WHERE o.id IS NOT NULL模拟EXISTS）
示例：把 SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 1) 改为
SELECT DISTINCT u.* FROM users u INNER JOIN orders o ON o.user_id = u.id AND o.status = 1;
用 EXISTS 替代 IN 的实际效果差异
IN 和 EXISTS 看似等价，但在千万级数据下执行路径完全不同：
-
IN (SELECT ...)在 MySQL 5.6+ 可能被转为半连接（semi-join），但若子查询返回 NULL 或结果集大，仍可能退化为全量匹配 -
EXISTS天然支持短路：找到第一条匹配就退出，不扫完整个子表 - 两者都依赖外层字段时，仍是相关子查询，
EXPLAIN里照样出现DEPENDENT SUBQUERY—— 所以光换语法没用，必须配合 JOIN 改写
真正有效的替换是：把 WHERE id IN (SELECT user_id FROM logs WHERE type='login') 改成 INNER JOIN logs l ON l.user_id = t.id AND l.type = 'login'，并确保 logs(user_id, type) 有联合索引。
不相关子查询其实不用动，但得会识别
不相关子查询（比如 WHERE salary > (SELECT AVG(salary) FROM employees)）通常只执行一次，优化器会物化或常量折叠。容易踩的坑是误写成相关形式：
- 漏删子查询里的外层引用，比如写成
(SELECT AVG(salary) FROM employees e2 WHERE e2.dept = emp.dept)，瞬间从 1 次变成 N 次 - 在 MySQL 中可通过
EXPLAIN FORMAT=TREE看是否落在Materialize节点下；PostgreSQL 用EXPLAIN (ANALYZE, VERBOSE)查看 SubPlan 是否标记never executed - SQLite 是个例外：旧版本几乎不物化，不相关子查询也可能重复计算
最常被忽略的一点：相关子查询的性能崩塌，往往不是因为没加索引，而是驱动表顺序错了——即使内表有索引，若外层先扫大表，优化器仍可能选择嵌套循环并全表扫内表。所以改写前，先看 EXPLAIN 的 type 是不是 ref 或 eq_ref，否则索引也白建。
