查视图执行计划看不到真实开销，因其仅展开为底层表操作；需用EXPLAIN (ANALYZE, BUFFERS)等获取运行时行为，并关注字段冗余、函数调用、并发影响及物化必要性。
查视图执行计划时为什么看不到真实开销
SQL 视图本身不存储数据，只是保存 SELECT 语句的定义，所以直接对 SELECT * FROM my_view 看执行计划，看到的是“展开后”的底层表操作——不是视图本身的开销，而是它引用的所有表、函数、JOIN 和过滤条件叠加后的实际路径。
常见错误现象：EXPLAIN 显示扫描行数极少，但查询却极慢；或视图里嵌套了另一个视图，执行计划层层展开后难以定位瓶颈点。
- 必须用
EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）或SET STATISTICS XML ON; SELECT ...（SQL Server）获取真实运行时行为，不能只看预估计划 - 如果视图含
ORDER BY或LIMIT，注意这些子句在定义中是否被保留——多数数据库（如 PostgreSQL 14+）允许在视图里写ORDER BY，但 MySQL 8.0 之前会忽略，导致应用层排序压力陡增 - 避免在视图里调用标量函数（如
my_udf(customer_id)），这类函数会在每行上重复执行，且无法下推到索引层
监控视图调用频次和并发影响
视图被高频调用时，问题往往不出在单次查询慢，而在连接堆积、缓存失效或锁竞争。比如一个报表视图每天被调度任务调用 2000 次，每次扫描 50 万行，即使平均耗时 800ms，也会持续抢占 shared_buffers 和 WAL 写入带宽。
使用场景：BI 工具直连数据库跑仪表盘、定时 ETL 脚本依赖视图输出、API 层未加缓存直接查视图。
- PostgreSQL 可查
pg_stat_statements，过滤query LIKE 'SELECT%FROM%my_view%'，重点关注total_exec_time和calls的比值 - MySQL 8.0+ 启用
performance_schema，查events_statements_summary_by_digest表，用DIGEST_TEXT匹配视图名（注意 digest 会标准化空格和大小写） - 若视图依赖的基表正在被大事务更新（如
UPDATE orders SET status = 'shipped' WHERE ...），即使视图只读，也可能因 MVCC 快照膨胀拖慢整个查询
物化视图 vs 普通视图：什么时候该换
普通视图每次调用都重算，物化视图（如 PostgreSQL 的 CREATE MATERIALIZED VIEW 或 Oracle 的 FAST REFRESH）把结果固化成物理表，但带来刷新延迟和额外维护成本。
性能/兼容性影响：PostgreSQL 物化视图不支持自动刷新，需手动 REFRESH MATERIALIZED VIEW；SQL Server 的索引视图要求严格（SCHEMABINDING、确定性函数等），否则创建失败并报错 Msg 1940, Level 16, State 1。
- 适合物化的典型场景：聚合统计类视图（
GROUP BY date_trunc('day', created_at)）、跨多租户汇总、计算成本高且更新频率低（如每日凌晨刷新一次） - 警惕“伪物化”：有些团队用定时任务把视图结果 INSERT INTO 临时表，但没加
TRUNCATE + INSERT原子性控制，导致下游查到脏数据或锁表超时 - MySQL 没有原生物化视图，替代方案是用
CREATE TABLE AS SELECT加事件调度器，但要注意EVENT默认不开启，需确认event_scheduler = ON
视图字段过多引发的隐性负载
一个视图定义了 50 个字段，但业务代码只用其中 3 个（如 SELECT id, name, status FROM user_summary_view），数据库仍会计算全部字段——包括 JSON 字段拼接、子查询 COUNT、窗口函数排名等冗余计算。
容易踩的坑：前端框架自动生成 SELECT * 请求；ORM 配置默认加载全部视图列；视图里用了 COALESCE(a.col, b.col, 'N/A') 这类表达式，即使 a.col 不为空，b.col 仍会被评估（尤其 b.col 是子查询时）。
- 用
pg_depend（PostgreSQL）或sys.dm_exec_describe_first_result_set（SQL Server）检查视图实际被哪些列引用，再反向精简定义 - 对宽视图做分层设计：基础视图（核心字段 + 索引友好）、扩展视图（含计算字段/JSON），让不同消费方各取所需
- MySQL 中视图字段别名若含特殊字符（如空格、括号），必须用反引号包裹，否则
SELECT `user count` FROM v_report会报错Unknown column 'user count' in 'field list'
最常被忽略的一点：视图里的 CASE WHEN 如果分支太多、嵌套过深，不仅影响可读性，还会让优化器放弃某些谓词下推机会，导致本可走索引的条件变成全表扫描。别只盯着执行时间，先看它扫了多少行。
