视图定义含派生表时，优化器直接放弃下推判断：因物化导致基表索引丢失、WHERE条件无法抵达存储引擎层，EXPLAIN中Extra退化为Using where；聚合、DISTINCT、远程源、权限限制等均破坏语义等价性，使下推失效。
视图定义含派生表时，优化器直接放弃下推判断
MySQL 和旧版 SQL Server 在遇到 FROM (SELECT ...) 这类内联子查询（即派生表）时，会先物化内层结果为临时结构，再执行外层逻辑。此时原始基表的索引信息、字段可下推性全部丢失，WHERE 条件只能在 Server 层过滤，无法抵达 InnoDB 或存储引擎层。
常见表现是：EXPLAIN 中 Extra 字段从 Using index condition 退化为 Using where，联合索引中非最左列的过滤失效（比如 (name, age) 索引上 WHERE age > 25 不走 ICP）。
- MySQL 5.7 默认不合并视图，嵌套一层就断链；8.0+ 有改进但对多层
FROM (SELECT FROM (SELECT))仍保守 - SQL Server 对普通视图几乎从不尝试下推，除非启用
SCHEMABINDING+ 索引视图 - PostgreSQL 的视图展开能力较强，但一旦含
GROUP BY、WINDOW或不可变函数（如random()），下推也会被禁用
视图含聚合或 DISTINCT 时，外层 WHERE 失去语义锚点
聚合视图（如 GROUP BY user_id）输出的是分组后的新行集，每行已不是基表原始记录。此时外层 WHERE status = 'active' 没有对应字段可绑定——status 可能被 MAX(status) 替代，也可能根本没出现在 SELECT 列表中。
优化器无法确认该条件是否等价于在基表上过滤，更不敢把它“翻译”成引擎层的索引扫描谓词。
-
DISTINCT视图隐含去重逻辑，外层条件可能作用于去重前还是去重后？语义模糊，优化器选择不推 - 含
COUNT(*)、SUM(amount)的视图，外层WHERE cnt > 10是合法语法，但和基表字段无关，天然无法下推 - 即使视图里显式写了
WHERE status = 'active'，外层再写同条件也不会复用，因为优化器不保证两次过滤逻辑一致
跨库/远程视图导致下推路径被硬性截断
当视图引用了链接服务器（Linked Server）、外部数据源（如 OPENQUERY）或联邦表时，SQL Server 和 MySQL 会默认把整个视图结果拉到本地内存再处理。这是安全策略，而非性能缺陷——数据库无法信任远端是否支持相同谓词下推语义。
典型错误写法：SELECT * FROM v_remote_orders JOIN local_customers ON ... WHERE v_remote_orders.order_date > '2026-01-01'，这个 WHERE 几乎必然失效。
- 必须改用
OPENQUERY(remote_srv, 'SELECT ... WHERE order_date > ''2026-01-01''')手动下推 - MySQL 的
FEDERATED引擎同样不支持条件下推，所有过滤都在本地执行 - PostgreSQL 的
postgres_fdw支持部分下推，但需手动开启use_remote_estimate = on并验证EXPLAIN输出
权限与 DEFINER 设置让下推变成不可控变量
视图创建时若未指定 DEFINER，或调用者权限不足以访问基表某些字段，优化器可能降级为保守执行路径：宁可全量扫描，也不冒险下推未知权限下的索引谓词。
尤其当视图字段来自表达式（如 UPPER(name)）或计算列，而基表上无对应函数索引时，下推既无意义也无可能。
- MySQL 中
sql_mode含STRICT_TRANS_TABLES时，隐式类型转换失败会导致下推中断 - PostgreSQL 的行级安全策略（RLS）若启用，视图下推需额外校验策略谓词，常被跳过
- SQL Server 的列级权限缺失，会使视图字段返回
NULL，外层WHERE判断失效，优化器干脆绕过下推逻辑
真正影响下推成败的，往往不是语法对错，而是优化器对“条件安全性”的判断——它需要确信：下推后的结果集与不下推完全等价。任何引入不确定性（派生表、聚合、远程源、权限隔离）的设计，都会让这个等价性验证失败。
