过滤条件下推能减少数据页读取量，因引擎可在读取阶段跳过不满足条件的数据页；MySQL中子查询包裹、UNION/GROUP BY后接WHERE、索引列用函数、隐式类型转换等写法会阻止下推。
过滤条件下推能减少数据页读取量
因为数据库引擎在执行 JOIN 时，如果外层的 WHERE 条件没下推到子查询或驱动表内部，就会先全量扫描整张大表（比如几千万行的 orders），再在内存里做 JOIN 和过滤。而下推后，引擎能在读取阶段就跳过不满足条件的数据页——哪怕只加一个 status = 'paid'，也可能让实际读取的数据页从 12000 降到 300。
MySQL 中哪些写法会阻止条件下推
以下常见结构会让优化器放弃下推，导致全表扫描后再过滤：
- 子查询包裹：如
(SELECT * FROM orders WHERE user_id IN (...)) AS t，外层再加AND t.status = 'paid' - 使用
UNION或GROUP BY后接WHERE - 对索引列使用函数：如
WHERE DATE(create_time) = '2026-11-01'—— 这不仅让索引失效，也切断下推路径 - 隐式类型转换：比如
user_id是INT，但写成WHERE user_id = '123'，MySQL 可能放弃下推优化
用 EXPLAIN 验证是否发生下推
关键看 EXTRA 列是否出现 Using where 且同时有 Using index 或 Using index condition。如果只有 Using where 而没有 Using index condition，说明过滤是在存储引擎返回数据后由 Server 层做的，没下推。
对比两个语句：
EXPLAIN SELECT u.name, o.amount FROM users u INNER JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid';
和
EXPLAIN SELECT u.name, o.amount FROM users u INNER JOIN (SELECT * FROM orders) o ON u.id = o.user_id WHERE o.status = 'paid';
后者在 o 表的 EXTRA 列大概率显示 Using where，且 rows 值接近全表行数。
手动强制下推的可行手段
不是所有场景都能靠优化器自动完成，有时得干预：
- 把过滤条件直接写进
ON子句：如INNER JOIN orders o ON u.id = o.user_id AND o.status = 'paid'（对INNER JOIN等效，但明确告诉优化器该条件属于连接上下文） - 改用
STRAIGHT_JOIN并确保小表/高选择性表为驱动表，再把条件放在其WHERE中 - 拆分复杂子查询，用临时表或 CTE（MySQL 8.0+）显式物化中间结果，并在建表时加好索引
真正难的不是知道“要下推”，而是判断哪一层的嵌套、哪个别名、哪条 JOIN 边界阻断了下推——这往往需要结合 EXPLAIN FORMAT=TREE 看完整执行树，而不是只盯 EXPLAIN 的扁平输出。
