视图不是真正的表，而是虚拟表，不存储数据，仅保存查询定义，每次查询时动态执行SELECT语句获取基表数据。
CREATE VIEW 定义的视图本身不存数据，每次查询都实时执行背后的 SELECT 语句——它不是缓存，也不是物化表。想靠它“提升性能”往往适得其反，除非配合特定数据库的物化视图功能（如 PostgreSQL 的 MATERIALIZED VIEW，MySQL 原生不支持）。
视图到底是不是一张“表”？
不是物理表，是语法层的别名封装。你对 my_user_order_view 执行 SELECT * FROM my_user_order_view WHERE status = 'paid'，数据库实际做的是：把 WHERE 条件“下推”进视图定义的原始 SELECT 里，再执行完整查询。这意味着：
- 视图字段必须全部来自基表，不能是表达式或常量（除非显式命名，如
COUNT(*) AS total） - 如果视图里用了
DISTINCT、聚合函数、GROUP BY、子查询或UNION，那它大概率不可更新（INSERT/UPDATE/DELETE会报错） -
EXPLAIN查看执行计划时，看到的是展开后的全链路 SQL，不是“查一张表”
什么时候该用 CREATE VIEW 而不是直接写 SQL？
核心判断标准就一个：有没有多个地方重复写同一段复杂逻辑。比如电商后台要反复查“近30天已支付订单的用户昵称、商品类目、实付金额”，且涉及 users、orders、order_items、products、categories 五张表 JOIN + 多层过滤 + COALESCE 处理空值。
这时建视图的价值才真正体现：
- 应用代码里只需
SELECT * FROM recent_paid_orders，不用拼接 10 行 JOIN - BI 工具连上去就能当普通表拖拽字段，不用写自定义 SQL
- 后续加个“排除测试账号”条件，只改视图定义，所有调用方自动生效
- DBA 可以单独给这个视图授
SELECT权限，不暴露底层任意一张基表
MySQL 中创建视图的常见翻车点
MySQL 对视图限制比 PostgreSQL / SQL Server 更严格，容易踩坑：
-
ALGORITHM = MERGE是默认行为，但若视图含聚合或子查询，MySQL 会自动切到TEMPTABLE，导致无法下推外部WHERE条件，性能骤降 - 视图中引用了函数（如
NOW()、USER()），每次查询结果可能不同——这没问题，但别误以为它是“快照” - 基表字段改名或删列后，视图不会自动失效；
SELECT *在视图定义里是危险操作，会导致后续CREATE VIEW失败或字段错位 - 权限上：用户要有视图定义中所有基表的
SELECT权，才能查这个视图；哪怕只查一列，也得有整张基表的权限（MySQL 8.0.22+ 支持更细粒度，但需显式开启）
替代方案比硬套视图更实用的场景
不是所有“简化查询”需求都适合视图。遇到这些情况，优先考虑别的办法：
- 只是临时分析？用 CTE：
WITH paid_orders AS (SELECT ...) SELECT ... FROM paid_orders WHERE ... - 需要固定快照或加速聚合？建汇总表 + 定时任务刷新，比依赖视图靠谱
- 应用层频繁拼条件？封装成 DAO 方法或 ORM 查询构建器，比 DB 层抽象更灵活
- 跨库或异构数据源？视图无能为力，得靠 Flink / dblink / 应用层聚合
视图真正的价值不在“省几行 SQL”，而在于把一段被多处依赖的、业务语义明确的查询逻辑，锚定在一个可授权、可维护、可演进的数据库对象上。一旦开始用，就得把它当成接口契约来对待——字段含义、空值约定、时间范围边界，都得文档化。否则半年后谁都不敢动它。
