MySQL中WHERE内子查询性能差，因可能对主表每行重复执行，导致隐式嵌套循环；应改用JOIN、派生表或CTE预计算，并确保关联字段有索引。
子查询写在 WHERE 里，为什么 MySQL 慢得像卡住？
因为数据库引擎很可能对主表每行都执行一次子查询，相当于隐式嵌套循环。特别是当主表有 10 万行、子查询又涉及非索引字段时，EXPLAIN 会显示 type: ALL 和高 rows 估算值。
- 典型场景：
SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'East')—— 表面简洁，但若customers.region没索引，子查询就变成全表扫描 × 主表行数 - 更危险的是关联相关子查询：
SELECT o.* FROM orders o WHERE o.amount > (SELECT AVG(amount) FROM orders WHERE customer_id = o.customer_id)，MySQL 5.7 默认无法物化子查询，每次都要重算 - 解决核心：把“为每行求一个值”的逻辑，转成“先算好所有值，再一次性匹配”
用 JOIN 替代 IN / EXISTS 子查询，但别直接硬连
JOIN 不等于自动变快；没过滤、没索引、字段类型不一致，照样拖垮性能。
- 先确保关联字段都有索引：
ALTER TABLE customers ADD INDEX idx_region (region)；ALTER TABLE orders ADD INDEX idx_customer_id (customer_id) -
IN子查询优先转为INNER JOIN（不是LEFT JOIN）：SELECT o.* FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE c.region = 'East'
-
EXISTS类型更适合用LEFT JOIN ... IS NOT NULL或保留为EXISTS（现代 MySQL 8.0+ 对EXISTS优化更好），但必须确认子查询里有明确的WHERE条件限制范围 - 注意字段类型：如果
orders.customer_id是INT，而customers.id是BIGINT，隐式转换会让索引失效
WHERE 中的标量子查询，用派生表预计算
当子查询只返回单个值（比如每个客户的平均订单额），直接放 WHERE 里就是灾难。应该先算出这个映射关系，再 JOIN 回去。
- 错误写法：
SELECT * FROM orders o WHERE o.amount > (SELECT AVG(amount) FROM orders WHERE customer_id = o.customer_id) - 正确做法：把子查询拎出来作为派生表，加索引提示（必要时）：
SELECT o.* FROM orders o INNER JOIN (SELECT customer_id, AVG(amount) avg_amt FROM orders GROUP BY customer_id) t ON o.customer_id = t.customer_id AND o.amount > t.avg_amt
- 如果派生表结果集大，考虑建临时表并加索引：
CREATE TEMPORARY TABLE tmp_avg AS SELECT ...; CREATE INDEX ix_tmp_cid ON tmp_avg(customer_id); - MySQL 8.0+ 可用 CTE 提升可读性，但注意 CTE 默认不物化（除非加
/*+ MATERIALIZE */hint）
EXISTS 比 IN 快？别信默认经验，看执行计划
老经验说 “EXISTS 总比 IN 快”，但在主表小、子查询结果集也小时，IN 可能走 range 索引更快；反之，子查询结果巨大时，EXISTS 的短路特性才有优势。
- 真正该盯的是
EXPLAIN输出里的type和key字段：type: eq_ref或ref才算走索引；key: NULL就是白写了 - 用
IN时，子查询结果不能超 1000 项（MySQL 默认限制），否则报错Subquery returns more than 1 row；而EXISTS没这问题 - 如果子查询含
ORDER BY或LIMIT，IN会报错，EXISTS则忽略这些子句——这不是功能差异，是语义限制
最常被忽略的一点：关联子查询里引用外部表字段时，MySQL 可能无法下推条件，导致子查询执行计划固定不变。这时候加 STRAIGHT_JOIN 强制驱动表顺序，或拆成两步查，反而更稳。
