嵌套子查询在MySQL中易变慢，因5.7及更早版本对IN/EXISTS常采用循环嵌套执行：外层每行都重执行内层查询，无物化缓存，导致I/O与解析开销爆炸。
为什么嵌套子查询在MySQL里容易变慢
因为MySQL（尤其是5.7及更早版本）对IN、EXISTS类子查询常采用“循环嵌套执行”策略：外层每查一行，内层就重新执行一次子查询，没有物化缓存。如果外层结果集有10万行，子查询就可能被执行10万次——哪怕内层表只有几千行，I/O和解析开销也迅速爆炸。
典型卡顿场景包括：SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active')，当orders表很大而users表带条件过滤时，性能断崖式下跌。
用JOIN替代IN子查询的实操要点
把IN子查询转为INNER JOIN，让优化器走哈希连接或索引驱动，避免重复执行。但要注意语义等价性——IN天然去重，而JOIN可能产生重复行。
- 加
DISTINCT或GROUP BY保证结果一致，例如：SELECT DISTINCT o.* FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE u.status = 'active'
- 若原查询是
WHERE user_id IN (SELECT id FROM ...)且users.id是主键，则JOIN后无需DISTINCT（一对一关系） - 务必确认
JOIN字段有索引：比如orders.user_id和users.id都需有索引，否则变成全表扫描，比原子查询还慢
EXISTS子查询改写为LEFT JOIN + IS NULL的陷阱
当原逻辑是“查找不存在匹配的记录”，比如SELECT * FROM users WHERE NOT EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id)，直接用LEFT JOIN更高效，但写法容易出错。
- 正确写法：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL
- 错误写法：
WHERE o.id IS NULL——如果orders.id允许NULL，或没被选中，会导致逻辑错误 - 关键点：必须用
JOIN条件中的外键字段判空（这里是o.user_id），不是随便选一个字段 - 如果
orders.user_id没索引，LEFT JOIN会极慢；此时先建索引比改写SQL更重要
哪些子查询不能/不该直接JOIN改写
不是所有子查询都适合硬转JOIN。强行改写可能引入错误或更差性能。
- 聚合子查询：
SELECT name FROM users WHERE age > (SELECT AVG(age) FROM users)——这种必须保留子查询，或提前算好值传入 - 相关子查询含
LIMIT或ORDER BY：SELECT * FROM products p1 WHERE price = (SELECT price FROM products p2 WHERE p2.category = p1.category ORDER BY updated_at DESC LIMIT 1)，JOIN无法表达“每个分类最新一条”的语义 - 子查询返回多列多行但只用于
IN单字段：如WHERE (a,b) IN (SELECT x,y FROM t)，MySQL 5.7不支持多列IN的JOIN等价写法，8.0+可用ROW(a,b)语法，但兼容性需评估
真正难优化的，往往是那些看似简单、却因数据分布倾斜或缺失统计信息而让优化器选错执行计划的子查询——这时候看EXPLAIN FORMAT=TREE比盲目改写更有用。
