外部查询变慢大概率因触发相关子查询（DEPENDENT SUBQUERY），即外层每行都重执行内层逻辑；需检查EXPLAIN中rows是否暴增、type是否退化为ALL/index、Extra是否含Using temporary，并确保子查询条件字段在联合索引最左前缀上。
WHERE 条件改了，外部查询却变慢，大概率不是条件本身的问题，而是触发了相关子查询（DEPENDENT SUBQUERY）——外层每行都重新执行一次内层逻辑。
EXPLAIN 看到 DEPENDENT SUBQUERY 就该停手
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，比猜逻辑靠谱得多。
