视图性能瓶颈源于底层SELECT未走索引或降级为TEMPTABLE；应先用EXPLAIN分析执行计划，避免函数过滤、隐式转换，优先用CTE或存储过程替代复杂视图。
WHERE 条件没走索引，视图一查就慢
视图本身不存数据，只是封装了 SELECT；如果底层查询的 WHERE 条件无法命中索引，每次调用视图都会全表扫描。关键不是“视图怎么写”，而是“视图里那条 SELECT 的执行计划是否高效”。
实操建议：
- 在创建视图前，先单独执行它的主体查询，用
EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）看是否走了索引 - 避免在过滤字段上用函数，比如
WHERE YEAR(created_at) = 2024会跳过索引；改成WHERE created_at >= '2024-01-01' AND created_at - 复合索引顺序要匹配查询条件顺序，例如视图中常写
WHERE status = ? AND category = ?，那就建INDEX(status, category)，反过来效果差 - PostgreSQL 中，如果视图含
ORDER BY且外层再加LIMIT，可能触发排序+限制合并优化；但 MySQL 视图不支持下推LIMIT，得靠物化或重写逻辑
SELECT * 在视图里是性能隐形杀手
视图定义里写 SELECT * 看似省事，实际会让优化器无法剪枝：哪怕你只取其中 2 个字段，数据库仍可能加载所有列（尤其含 TEXT、JSON 大字段时），IO 和内存压力陡增。
实操建议：
- 视图定义必须显式列出所需字段，一个不多一个不少，比如
SELECT id, name, status FROM orders WHERE deleted = false - 如果源表有计算字段或冗余字段（如
full_name AS CONCAT(first_name, ' ', last_name)），确认业务真需要它再放进视图，否则留到应用层拼 - MySQL 8.0+ 支持“不可见列”，但视图不继承该属性；别指望靠隐藏列来规避
SELECT *的开销
JOIN 太多导致视图嵌套后执行计划崩坏
视图 A JOIN 视图 B，B 又基于视图 C，三层嵌套后，优化器容易放弃统计信息推导，退化成嵌套循环或临时表，尤其在 PostgreSQL 中常见 Hash Join 被替换成低效的 Nested Loop。
实操建议：
- 单个视图最多 JOIN 2 张基础表，超过就拆成中间物化表（如用
CREATE TABLE AS或定期刷新的分区表） - 避免在视图里 JOIN 大宽表（比如用户资料表含 50+ 字段），优先用子查询关联主键，再按需查详情
- SQL Server 中，视图若含
OUTER JOIN，外层再加WHERE可能导致谓词无法下推，直接改用 CTE + 显式LEFT JOIN更可控 - 所有 JOIN 字段必须有索引，且类型严格一致——
INT对BIGINT、VARCHAR(50)对VARCHAR(100)都可能让索引失效
MySQL 视图无法下推 WHERE 到子查询
这是 MySQL 特有坑：定义为 CREATE VIEW v_orders AS SELECT * FROM (SELECT id, amount FROM orders) t，然后查 SELECT * FROM v_orders WHERE amount > 100，执行计划里往往显示对内层子查询全扫，而不是把 amount > 100 下推进去。
实操建议：
- MySQL 5.7+ 开启
optimizer_switch='derived_merge=on'（默认开启），但仅对简单子查询有效；复杂嵌套仍不行 - 绕过办法：不用子查询封装，直接写平铺 SQL；或者改用 CTE（MySQL 8.0+）——CTE 默认可下推谓词，比视图靠谱
- 如果必须用视图且依赖动态过滤，考虑用存储过程包装，传参生成定制化 SQL，比硬写视图灵活得多
- 注意
ALGORITHM = MERGE是理想状态，但遇到聚合、去重、变量等就会自动降级为TEMPTABLE，这时视图彻底变成黑盒，毫无优化空间
真正卡住性能的，往往不是语法多难，而是索引没对上、字段类型隐式转换、或者 MySQL 把你写的视图悄悄转成了临时表。动手前先看执行计划，别信“视图看起来简洁”这种直觉。
