子查询在where中慢是因为相关子查询对每行外层数据都执行一次，导致n×m级扫描；应改用join、确保索引、避免函数索引失效，并用explain验证执行计划。
子查询写在 WHERE 里为什么慢得离谱
因为 MySQL 在 WHERE 子句中使用相关子查询（即子查询依赖外层表字段）时，可能对每行外层数据都执行一次子查询，形成 N×M 级扫描。比如：
SELECT * FROM orders o WHERE o.customer_id IN (SELECT id FROM customers c WHERE c.status = 'active' AND c.id = o.customer_id);
这里 c.id = o.customer_id 让子查询变成“相关”的，MySQL 5.6 及更早版本几乎无法优化，即使加了索引也常走全表扫描。
常见错误现象：EXPLAIN 显示 type 是 ALL 或 index，rows 列数值极大，Extra 出现 Using where; Using join buffer。
- 优先改写为
JOIN：上例可转成INNER JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active' - 确认子查询是否真需“相关”：如果只是过滤固定集合，用非相关子查询（如
(SELECT id FROM customers WHERE status = 'active')），MySQL 能物化为临时表 - MySQL 8.0+ 开启
optimizer_switch='materialization=on'可提升非相关子查询性能，但不解决相关子查询本质问题
IN、EXISTS、JOIN 三者选哪个
语义不同，执行计划和性能差异明显，不能简单互换。
IN 适合右侧结果集小且无 NULL 值的场景；EXISTS 天然适合相关子查询，且对 NULL 安全；JOIN 最适合需要取子查询中额外字段或做聚合的场景。
-
IN遇到NULL会整体返回空结果（如1 IN (1,2,NULL)→UNKNOWN→ 过滤掉该行），而EXISTS不受 NULL 影响 - 当子查询结果集较大（比如 > 1000 行），
IN可能触发“IN-list limit”，MySQL 会退化为全表扫描；此时EXISTS或JOIN更稳 -
EXISTS在有合适索引时通常走range或ref，但必须确保子查询的关联字段上有索引（如EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id)，需logs(order_id)索引）
子查询放在 SELECT 列表里要注意什么
标量子查询（返回单值、单行）可以出现在 SELECT 列表，但极易引发性能灾难，尤其在外层是大表时。
