视图适合长期复用、权限隔离和逻辑封装，必须用于跨用户/会话共享的固化查询；CTE仅限单语句内联，临时表仅限当前会话，二者均无法替代视图的对象级共享能力。
视图适合需要长期复用、权限隔离或逻辑封装的场景，不是“写一次、用一次”的临时方案。
什么时候必须用视图而不是CTE或临时表
当你要把一个查询逻辑固化成数据库对象，供多个用户、多个应用、多个会话反复调用，且不希望每次执行都重新定义结构时，只能选视图。CTE 生命周期只限单条 SQL，临时表只在当前会话有效，二者都无法跨连接、跨用户共享。
- API 或报表系统频繁调用同一数据口径（比如
sales_summary_view） - 需要对不同角色暴露不同字段集（如财务看全量金额，运营只看分渠道汇总）
- 基表结构可能变动，但上层应用依赖固定列名和语义（通过视图重映射列、加计算字段、屏蔽废弃字段）
视图 vs CTE：别在存储过程里硬套视图
CTE 是语法糖，执行时被优化器展开或内联；视图是对象，每次查询都会重新执行其定义 SQL。如果在存储过程中反复查同一个复杂逻辑，用 CTE 比查视图更可控——因为你能看到完整执行计划，而视图可能隐藏了嵌套层级、让优化器误判统计信息。
- 视图里嵌套了另一个视图？执行计划可能无法下推
WHERE条件，导致全量扫描 - MySQL 中视图不能含
ORDER BY（除非带LIMIT），否则CREATE VIEW直接报错 - PostgreSQL 允许
SELECT *创建视图，但基表加字段后，视图输出列会变，下游INSERT INTO ... SELECT *可能崩
视图 vs 临时表：别为了“看起来像表”就建视图
临时表支持索引、可更新、可多次读写；视图只是个 SELECT 语句别名，背后没物理存储。如果你需要缓存中间结果、加速后续 JOIN、或做 UPDATE/DELETE，视图做不到，必须用临时表。
- 想在后续语句中对中间结果建索引？只能用
CREATE TEMPORARY TABLE - 需要在事务中修改中间数据（比如标记已处理订单）？视图不可写，除非满足极严格的“可更新视图”条件（MySQL 要求单表、无聚合、无去重）
- 临时表能用
#tmp（SQL Server）或TEMPORARY（MySQL）显式控制生命周期；视图一旦创建就一直存在，得靠人工或脚本管理
真正容易被忽略的是权限链：视图查询失败，往往不是语法问题，而是创建者对基表没有 SELECT 权限，或者调用者没被授予对该视图的访问权——而 CTE 和临时表的权限检查发生在执行时刻，链条更短、更透明。
