SQL视图不支持“布尔逻辑下推”，实际是查询优化器将外层WHERE条件与视图定义合并后执行谓词下推；是否减少扫描行数取决于合并后的条件能否被索引覆盖及ICP是否生效，需通过EXPLAIN的key和Extra字段判断。
SQL视图本身不支持“布尔逻辑下推”这个独立机制——它不是数据库引擎定义的优化技术，而是用户常对「谓词下推（Predicate Pushdown）在视图场景下的表现」产生的误称。真正起作用的是查询优化器对视图定义 + 外层 WHERE 条件的联合重写能力。
视图定义不固化过滤逻辑
创建视图时，CREATE VIEW 仅保存 SELECT 语句文本，不预计算、不物化、不绑定执行计划。视图像一个带参数的模板，每次被引用时，优化器会把外层条件“合并进”视图内部的 WHERE 子句，再统一生成执行计划。
例如：
CREATE VIEW v_active_orders AS SELECT o.id, o.user_id, o.amount, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active';
当执行 SELECT * FROM v_active_orders WHERE amount > 1000; 时，优化器实际等价处理为：
SELECT o.id, o.user_id, o.amount, u.name FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'active' AND o.amount > 1000;<p>——这才是谓词下推生效的前提：条件被合并后，能推动到基表扫描阶段执行。</p><h3>扫描行数是否减少，取决于能否下推到索引扫描层</h3><p>扫描行数（<code>rows</code> 字段）是否下降，不取决于“用了视图”，而取决于合并后的完整 WHERE 条件能否被索引覆盖、是否满足最左前缀匹配、以及是否触发 ICP。</p>
- 若
orders表有索引idx_amount_user（amount,user_id），则amount > 1000可直接走索引 range 扫描，rows显著降低 - 若只有
user_id单列索引，而u.status = 'active'在users表上无索引，则 JOIN 前无法有效过滤users，rows可能仍很高 - 若视图里写了
WHERE u.status = 'active'，但外层又加了AND u.created_at > '2025-01-01'，而users表没有(status, created_at)联合索引，这部分仍需 Server 层过滤，不减少扫描行数
EXPLAIN 中看不到 “using index condition” 就说明没下推成功
判断谓词是否真正下推到存储引擎层，唯一可靠方式是看 EXPLAIN 的 Extra 列：
- 出现
Using index condition→ ICP 生效，索引节点内完成部分过滤，回表次数减少 - 出现
Using where→ 过滤由 Server 层完成，所有索引匹配行都已回表，再逐行判断 - 视图内外条件合并后，若
EXPLAIN显示type=ALL或rows接近全表 → 下推失败或索引失效
特别注意：视图嵌套过深（比如视图 A 引用视图 B）、或含聚合/窗口函数/UNION，会导致优化器放弃合并条件，外层 WHERE 完全无法下推——此时 rows 就是视图物化结果集的大小，性能灾难往往从这里开始。
复杂点在于，视图只是语法糖，真正决定扫描行数的永远是合并后的谓词能否被索引结构承载。别迷信视图封装，先看 EXPLAIN 里 key 和 Extra 到底填了什么。
