SQL视图不占用额外物理存储空间，仅保存SELECT查询语句而非数据副本；其定义存于系统表中，体积极小；性能取决于底层查询，不预计算、不自动索引；权限控制是核心价值。
SQL视图不占用额外物理存储空间
视图只是保存的 SELECT 查询语句，不是数据副本。无论你建 1 个还是 100 个视图，只要底层表没变，磁盘上就不会多出一行数据。
常见错误现象：SHOW TABLE STATUS 查不到视图的 Data_length 或 Index_length；用 du -sh 看数据库目录大小，增删视图前后完全一致。
注意点：
- 视图定义本身会存进系统表（如 MySQL 的
information_schema.VIEWS），但体积极小，通常几 KB 级别 - 某些 GUI 工具显示“视图大小为 0B”，容易误以为它“不存在”或“无效”，其实只是没数据实体
- 物化视图（如 PostgreSQL 12+ 的
MATERIALIZED VIEW）是例外——它真存数据，但标准 SQL 视图（CREATE VIEW）永远不物化
MyISAM 和 InnoDB 对视图行为无实质影响
视图是逻辑层对象，跟底层表用什么存储引擎无关。哪怕一个视图跨了 MyISAM 表和 InnoDB 表，只要查询语法合法，就能创建成功、执行无误。
但隐含差异会影响实际使用：
-
MyISAM不支持事务，如果视图里涉及多个表，而其中一张被并发TRUNCATE，查询可能中途失败或返回不一致快照 -
InnoDB支持 MVCC，视图查询能获得事务一致性读，更适配 OLTP 场景 - 外键约束只在
InnoDB生效，若视图依赖外键关联逻辑，换到MyISAM后约束失效，但视图本身仍可运行——只是逻辑保障没了
视图性能取决于底层查询，而非视图本身
视图不会“预计算”或“自动加索引”。每次 SELECT * FROM my_view，等价于原封不动展开视图定义里的 SELECT，再走一遍优化器。
容易踩的坑：
- 在视图里写
SELECT *，然后在外部再加WHERE，很可能导致全表扫描——优化器未必能把外部条件下推到子查询中 - 嵌套视图（视图查另一个视图）超过 2 层后，MySQL 5.7 及以前版本可能拒绝执行，报错
View 'xxx' references invalid table(s) or column(s) - 视图中用了
GROUP BY或窗口函数，但没在外部查询里显式指定排序，结果顺序不保证——这不是 bug，是 SQL 标准行为
权限控制是视图最常被忽略的实际价值
视图本质是访问控制代理。你可以让业务账号只能查 v_user_summary，而它背后是 JOIN users, orders, logs 三张敏感表，但用户看不到原始表名，也执行不了 INSERT/UPDATE。
实操建议：
- 建视图时用
SQL SECURITY DEFINER（默认），权限以定义者为准；若用INVOKER，则每次执行都校验调用者权限，更安全但调试麻烦 - 避免在视图里暴露
password_hash、id_card这类字段，即使原始表有权限限制，视图一旦开放，就等于绕过列级管控 - MySQL 8.0+ 支持角色（
ROLE），建议把视图权限绑定到角色，而不是直授给用户，后期回收更干净
真正复杂的不是语法，是搞清谁该看到什么、什么时候该走视图、什么时候该直接查表——这得看业务语义，不是看 CREATE VIEW 能不能敲出来。
