WHERE条件无法下推至含GROUP BY的视图内部，因聚合改变数据粒度，优化器无法安全提前过滤；典型表现为全表扫描，即使底层表有索引且外部仅查单值；UNION ALL+GROUP BY组合更彻底禁用谓词下推。
WHERE 条件无法下推到含 GROUP BY 的视图内部
视图定义中若包含 GROUP BY，外部查询的 WHERE 条件基本不会被下推到视图底层表。这是因为聚合操作改变了数据粒度，优化器无法安全地将过滤提前——它得先完成分组，才能知道哪些分组满足条件。
典型现象是：执行 EXPLAIN 后发现视图对应子计划仍扫描全表，哪怕外部只查一个 agent_id = 123；而该字段在视图底层表上明明有索引。
- MySQL/Oracle 对含
UNION ALL+GROUP BY的视图几乎完全禁用谓词下推（连 hint 都无效） - PostgreSQL 虽支持部分下推，但遇到
LATERAL、窗口函数或嵌套聚合时也会退化 -
WHERE写在视图外层，实际作用于聚合后的结果集，不是原始行
HAVING 和 WHERE 混用导致逻辑错位
很多人试图用 HAVING 在视图里“预过滤”，但这是误解：HAVING 是对聚合结果的筛选，不能替代 WHERE 的行级过滤。视图一旦定义了 GROUP BY，它的输入就已是聚合前的数据流，外部条件进不去。
例如视图定义为 CREATE VIEW v_sales AS SELECT region, SUM(amount) s FROM orders GROUP BY region，外部写 SELECT * FROM v_sales WHERE region = 'CN'，数据库仍可能先算出所有 region 的 sum，再丢弃非 'CN' 行。
- 真正有效的过滤必须落在
orders表上，比如WHERE order_date >= '2025-01-01' - 若想让该条件生效，得把
order_date加进视图定义，并在外部WHERE中引用它 - 否则优化器看不到“可下推路径”，只能走全量聚合 + 外层过滤的老路
用 SHOW CREATE VIEW 确认视图算法类型
执行 SHOW CREATE VIEW view_name，重点看 ALGORITHM 字段。若显示 ALGORITHM=TEMPTABLE，说明数据库强制物化中间结果，此时任何外部谓词都绝无下推可能。
这类视图常见于含聚合、UNION、子查询或非确定性函数（如 NOW()）的场景。它本质上是一张临时表，外部条件只能作用于这张临时表，而非源头。
- MySQL 8.0+ 默认倾向
TEMPTABLE，尤其当视图含DISTINCT或LIMIT - PostgreSQL 没有显式
ALGORITHM，但可通过EXPLAIN (ANALYZE, BUFFERS)观察是否出现 Materialize 节点 - 一旦确认是
TEMPTABLE，重构是唯一出路：拆成基础视图（仅SELECT ... FROM ... WHERE ...）+ 应用层聚合
替代方案：用 CTE 或物化表绕过视图限制
如果业务强依赖“带聚合的视图接口”，又要求高效过滤，直接放弃视图更实际。用 WITH 子句或物化表（如 PostgreSQL 的 CREATE MATERIALIZED VIEW）替代，能明确控制执行顺序和索引使用。
例如把原视图逻辑改写为：
WITH filtered_orders AS ( SELECT * FROM orders WHERE agent_id = ? AND order_date >= ? ) SELECT region, SUM(amount) FROM filtered_orders GROUP BY region;
这样过滤条件在聚合前就已生效，索引可用，执行计划清晰。
- CTE 不保证物化，但现代优化器（尤其是 PostgreSQL）通常会尊重其过滤边界
- 物化视图需手动
REFRESH，适合变化不频繁的统计口径 - 避免在视图里塞
CASE WHEN或多维GROUPING SETS，那会让下推逻辑彻底不可控
最常被忽略的一点：视图不是性能优化手段，而是逻辑封装工具。指望它自动加速聚合查询，等于让编译器替你做架构决策——它做不到，也不该做。
