外部查询变慢大概率因触发相关子查询（dependent subquery），即外层每行都重执行内层逻辑；需检查explain中rows是否暴增、type是否退化为all/index、extra是否含using temporary，并确保子查询条件字段在联合索引最左前缀上。

WHERE 条件改了，外部查询却变慢，大概率不是条件本身的问题，而是触发了相关子查询（DEPENDENT SUBQUERY）——外层每行都重新执行一次内层逻辑。

---

EXPLAIN 看到 DEPENDENT SUBQUERY 就该停手

这是最直接的信号：子查询里引用了外部表字段（比如 users.id = logs.user_id），优化器无法提前物化结果，只能嵌套循环执行。
例如：

SELECT u.name FROM users u 
WHERE u.id IN (SELECT user_id FROM logs WHERE user_id = u.id AND status = 'error');

只要 status = 'error' 这个条件没索引支撑，或者加了它反而让原有索引失效，就会导致内层 logs 表每次扫描行数暴增。

• 检查 EXPLAIN 的 rows 列：如果显示 50 万，但实际只返回几百行，基本确认是嵌套放大
• 看 type：若变成 ALL 或 index，且 Extra 含 Using where; Using temporary，说明没走索引还建了临时表
• 别只盯着“加了条件”，要确认这个条件字段是否在联合索引的最左前缀上——比如子查询是 WHERE user_id = ? AND status = ?，必须有 (user_id, status) 索引，单列 status 索引无效

---

改 WHERE 字段顺序可能让索引失效

联合索引 (a, b, c) 只能高效支持 WHERE a = ?、WHERE a = ? AND b = ?，但不支持 WHERE b = ? 或 WHERE b = ? AND c = ?。
子查询中若把原本能走索引的条件（如 a = ?）删掉，换成只过滤 b，就会退化为全索引扫描甚至全表扫描。

• 原写法：WHERE user_id = u.id AND created_time > '2026-01-01' → 有 (user_id, created_time) 索引，快
• 新写法：WHERE status = 'error' AND created_time > '2026-01-01' → 若无 (status, created_time) 索引，就只能扫全表
• 更隐蔽的是隐式类型转换：比如 user_id 是 BIGINT，但传入字符串 '123'，索引直接失效

---

加条件后子查询结果含 NULL，逻辑和性能双崩

NOT IN 遇到子查询返回 NULL，整个条件永远为 UNKNOWN，结果集为空——这不仅是语义错误，还会让优化器放弃所有下推尝试，强制走最保守路径。

• 现象：WHERE id NOT IN (SELECT user_id FROM logs WHERE status = 'error')，但 logs.user_id 允许为 NULL
• 后果：MySQL 不敢物化子查询，也不敢用哈希连接，只能反复判断 + 全表扫描主表
• 解法：要么加 AND user_id IS NOT NULL 显式排除，要么改用 LEFT JOIN ... WHERE right.user_id IS NULL，并确保 right.user_id 字段有非空约束或额外 IS NOT NULL 判断

---

真正卡住性能的，往往不是“多了一个条件”，而是那个条件让原本可物化的子查询，变成了每行都要重算的黑盒。改之前先跑一遍 EXPLAIN，重点盯 rows 和 Extra，比猜逻辑靠谱得多。