在数据库日常使用中，不少工程师遇到过这样的现象：对一张千万级表直接加where条件查询很快，但把同样条件放在基于该表建立的视图上，响应时间却成倍增加。要解释这种差异，必须深入到查询优化器如何展开视图以及生成执行计划的过程。视图本身不存储数据，它只是一条被保存的SELECT语句，当外层查询引用视图时，优化器会先做视图合并或展开，再把用户写的过滤条件拼接到内部查询中。
如果优化器能够把外层的过滤条件下推到视图定义的最底层表扫描操作上，数据库就能利用原表上的索引进行快速定位，此时视图查询与原表查询性能几乎一致。但现实里，很多写法会阻断这种下推，导致数据库先按视图逻辑把结果集完整算出来，再在顶层做过滤，自然就慢了。理解这一点，是调优视图性能的前提。
执行计划如何暴露视图查询的性能问题
要确认视图查询是否变慢源于下推失败，第一步是读取数据库给出的执行计划。以MySQL为例，对原表查询使用EXPLAIN命令，可以看到type列是range或ref，key列显示了使用的索引，rows列预估扫描行数很小。这说明优化器把条件用到了索引上。而对视图做相同条件的EXPLAIN，如果看到select_type出现DERIVED，或者Extra列有Using where且rows预估极大，往往意味着视图被当作派生表先物化。
在PostgreSQL里，可以通过EXPLAIN ANALYZE观察节点结构。正常下推时，底层Seq Scan或Index Scan节点会带有Filter条件，且启动代价低。若视图含干扰结构，计划里会出现Subquery Scan或CTE Scan包裹一层，外层再过滤，实际扫描行数等于视图输出总量。通过对比两张计划的节点差异，就能定位是不是下推被阻断。
下面是一段在MySQL中对比查看计划的简单示例，分别针对原表和视图：
-- 原表查询计划 EXPLAIN SELECT id, name FROM orders WHERE create_time >= '2023-01-01' AND status = 1; -- 视图查询计划 EXPLAIN SELECT id, name FROM v_orders_filter WHERE create_time >= '2023-01-01' AND status = 1;
从输出中可以重点看type和key字段。若视图查询的type变成ALL且key为NULL，而原表是range且key有值，基本可断定谓词没有下推，优化器选择了先全量展开视图再过滤。这种计划层面的证据，比单纯凭感觉说视图慢更有说服力，也为后续改写提供了方向。
哪些视图结构会阻止谓词下推
谓词下推失效通常不是优化器的bug，而是视图定义触碰了不可下推的规则。最常见的阻断因素是在视图里使用了聚合函数，比如GROUP BY配合COUNT、SUM。一旦视图需要分组汇总，外层的条件如果作用在聚合前的列上，数据库往往无法把条件推到聚合前，因为那会改变分组语义。此时只能先算聚合，再过滤结果。
另一个典型场景是视图中使用了DISTINCT或UNION。去重操作要求先拿到完整结果集才能判断重复，所以外层where很难穿透到去重前的基础表扫描。同样，UNION会把多个子查询的结果合并，优化器通常不会把单一条件拆开分别下推到每个分支并提前过滤，除非写法极简单。还有在视图SELECT列表里对列使用函数，例如WHERE YEAR(create_time) = 2023写在视图内，也会让原表索引失效并影响外层下推。
我们通过一个反面例子来看视图定义如何导致慢查询。以下视图因包含聚合而无法有效下推：
CREATE VIEW v_user_order_stat AS SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amt FROM orders GROUP BY user_id; -- 外层查询希望只看某个用户 SELECT * FROM v_user_order_stat WHERE user_id = 1001;
在上面定义中，GROUP BY user_id使视图必须先对所有用户聚合。即使外层只查user_id=1001，多数数据库也会先算全量聚合，再从结果找这一行。如果orders表很大，这显然比直接SELECT ... FROM orders WHERE user_id=1001 GROUP BY user_id慢得多。理解这些结构限制，才能知道哪些视图适合加条件、哪些视图该拆开重写。
通过改写与优化手段恢复下推能力
面对下推失效的视图，最直接的办法是改写查询，用内联子查询或CTE把过滤条件放在最底层。例如原本依赖一个含函数的视图，可以改为直接查原表并在where里写等价条件，让索引生效。如果业务必须保留视图，可建立参数化视图思路，把过滤字段作为视图定义的一部分，而非在外层追加。
在支持的数据库如PostgreSQL中，可以使用WITH子句把过滤提前，或利用物化视图针对固定维度预计算。对于MySQL，尽量保持视图定义简单，避免GROUP BY、DISTINCT，把聚合留到外层查询。若视图必须含聚合，可考虑在基础表上建索引覆盖聚合列，减缓全表扫描代价。同时定期用EXPLAIN验证改写后的计划是否出现索引范围扫描。
下面示例展示把阻塞下推的视图查询改写为直接带条件的原表聚合，恢复性能：
-- 改写前依赖视图，下推失败 SELECT * FROM v_user_order_stat WHERE user_id = 1001; -- 改写后直接查原表并提前过滤 SELECT user_id, COUNT(*) AS order_cnt, SUM(amount) AS total_amt FROM orders WHERE user_id = 1001 GROUP BY user_id;
这种改写让user_id=1001在扫描阶段就生效，若user_id上有索引，数据库只需读取极少数据再聚合，耗时从数秒降到毫秒。总结来说，视图慢的根因多在优化器无法把外层谓词下推到内部表扫描，通过读懂执行计划、规避阻断结构、主动改写查询，就能把视图查询速度拉回与原表同级的水平。