谓词下推实际发生在mysql优化器的prepare阶段，是rbo逻辑重写过程，而非手动改写sql触发；优化器解析语法树后，将满足独立性、非聚合、非跨表强耦合等前提的where条件直接嫁接到对应表的tablescan节点，在生成物理执行计划前完成。
MySQL 会自动做谓词下推，你写的 WHERE 条件大概率已被优化器提前应用到表扫描阶段 —— 但前提是条件可下推、索引可用、优化器没被禁用。
谓词下推实际发生在哪个环节？
它不是你在 SQL 里手动改写子查询才触发的机制，而是 MySQL 优化器在 prepare 阶段就完成的逻辑重写。优化器解析完语法树后，会逐层检查每个 WHERE 条件是否满足“可下推”前提：独立于其他表、不依赖聚合结果、不跨多表强耦合（如 t1.name = t2.name AND t1.id > 5 中的等值连接部分可下推，但混合条件可能无法拆分）。
一旦确认可下推，优化器就把该条件“嫁接”到对应表的扫描节点上，比如把 orders.amount > 1000 直接塞进 orders 表的 TableScan 操作里，而不是等 JOIN 完再过滤。
- 下推发生在优化器生成物理执行计划前，属于 RBO（基于规则的优化）阶段的常规动作
- MySQL 8.0.22+ 默认启用派生表谓词下推，8.0.29+ 支持 UNION 场景
- 下推与否不改变你写的 SQL 表面结构，只影响执行计划内部算子顺序
怎么确认谓词真的被下推了？
靠 EXPLAIN FORMAT=tree 或 EXPLAIN 的 Extra 字段最可靠。如果看到类似 Using where; Using index 或树形输出中 Filter 出现在 Table scan on xxx 下方，说明条件已下推到存储层；若 Extra 只有 Using where 且没提索引，大概率是 server 层过滤，没下推成功。
-
EXPLAIN FORMAT=tree SELECT * FROM orders JOIN users ON orders.user_id = users.id WHERE orders.amount > 1000;—— 观察Filter是否挂在orders扫描节点下 - 对比
EXPLAIN中rows值：下推后预估行数应显著减少（如从百万级降到千级） - 注意
possible_keys和key是否命中索引：没索引时，即使下推也仍是全表扫描 + 引擎层过滤
哪些情况会导致谓词下推失效？
下推不是万能的，常见失效点集中在语义依赖和配置限制上：
-
HAVING条件永远无法下推，因为它必须等聚合完成才能计算 - 涉及函数或表达式的列（如
WHERE YEAR(order_date) = 2023）通常无法利用索引，也就难以下推到底层扫描 - 使用了
optimizer_switch='derived_condition_pushdown=off'会全局禁用派生表下推 - 多表关联中，若
WHERE条件含跨表计算（如t1.x + t2.y > 100），优化器无法安全拆分，只能留到 JOIN 后过滤 - 视图或复杂子查询未展开（
ALGORITHM=TEMPTABLE）时，下推可能被阻断
手动写子查询真比让优化器自动下推更优吗？
绝大多数情况下不会 —— 现代 MySQL 优化器已足够智能，手写 (SELECT * FROM t WHERE cond) 这类子查询反而可能干扰优化器判断，导致额外物化（MATERIALIZE）开销。只有当明确观察到 EXPLAIN 显示条件未下推、且业务场景稳定（如固定分区裁剪）、同时你能保证子查询结果集足够小时，才值得尝试手动干预。
真正关键的是确保单表过滤条件写得“干净”：用裸列、避免函数包装、配合有效索引，剩下的交给优化器。
