视图性能问题源于底层查询低效、嵌套过深、SELECT *滥用、含不可优化函数及错误日期过滤。应避免三层以上嵌套、显式指定字段、移出动态函数、用范围条件替代函数提取。
SQL 视图本身不存储数据，只是保存查询定义，所以“视图慢”本质上是底层查询慢。性能问题往往不是视图导致的，而是使用方式或设计不当放大了原有低效逻辑。
视图嵌套过深，执行计划失控
多层视图嵌套（比如视图 A 引用视图 B，B 又引用视图 C）会让优化器难以生成高效执行计划。数据库可能无法下推谓词、无法有效利用索引，甚至对中间结果全表扫描。
- 避免三层以上嵌套，尤其不要在视图中再 SELECT * FROM 另一个复杂视图
- 用 EXPLAIN 或执行计划查看实际访问路径，确认是否出现未预期的临时表或全表扫描
- 关键场景优先用物化视图（如 PostgreSQL 的 MATERIALIZED VIEW）或应用层缓存替代深层嵌套
SELECT * 从视图读取，拖垮 I/O 和网络
定义视图时若用了 SELECT *，而调用方又习惯性写 SELECT * FROM v_user_info，会导致查出大量无用字段——包括大文本、JSON、LOB 类型列，白白增加磁盘读、内存占用和网络传输开销。
- 视图定义中明确列出所需字段，禁用 SELECT *
- 业务 SQL 调用视图时，只 SELECT 真正需要的列，哪怕多打几行代码
- 对含大字段的视图，可拆分为“主信息视图”和“详情扩展视图”，按需组合
视图中含不可优化的表达式或函数
在视图定义里使用 GETDATE()、NEWID()、CONVERT(..., GETDATE()) 或自定义标量函数，会阻止谓词下推、索引查找，甚至让整个查询变成非SARGable（无法走索引）。
- 把动态值（如当前时间）尽量移到外部 WHERE 条件中传入，而非写死在视图内
- 避免在视图 SELECT 列表中调用标量函数；改用内联表值函数（ITVF）或 JOIN 预计算表
- 日期范围过滤别写成 YEAR(OrderDate) = 2024，应改为 OrderDate >= '2024-01-01' AND OrderDate 2025-01-01'
误以为视图能自动优化，忽略统计信息更新
视图不缓存执行计划，但它的底层表如果长期未更新统计信息，优化器仍会基于过时分布做错误决策——比如该走索引却选了扫描，且这种问题在视图上更难察觉。
- 定期检查并更新基础表的统计信息（如 SQL Server 的 UPDATE STATISTICS，PostgreSQL 的 VACUUM ANALYZE）
- 对高频查询的视图所依赖的表，设置自动统计信息更新（如 SQL Server 中开启 AUTO_UPDATE_STATISTICS）
- 当视图响应突然变慢，优先排查底层表是否近期有大量数据变更而未触发统计更新
