视图是什么：一个 SELECT 语句的命名别名
视图不是真实表，也不存储数据，它只是保存了一条
SELECT查询语句的定义。每次查询视图时，MySQL 实际上是把视图定义中的 SQL 拆出来、重写进你的查询里，再执行——这叫“视图展开（view expansion）”。所以视图本身不占磁盘空间（除了定义元数据），但查询性能完全取决于底层表结构和索引是否合理。
创建视图时必须注意的三件事
用
CREATE VIEW定义视图看似简单，但容易踩坑： 视图中不能包含临时表、子查询中的
ORDER BY（除非配合
LIMIT），否则会报错
ERROR 1351 (HY000): View's SELECT contains a subquery in the FROM clause如果视图基于多个表 JOIN，且你后续想通过视图做
UPDATE或
INSERT，MySQL 要求该视图必须是“可更新的”——即只能涉及单个基表，或满足严格条件（如无聚合、无去重、无计算列等）
DEFINER和
SQL SECURITY影响权限行为：
SQL SECURITY DEFINER表示以定义者权限执行（常用于封装敏感查询），
SQL SECURITY INVOKER则按调用者权限检查——线上环境建议显式指定，避免权限意外失效
CREATE ALGORITHM = MERGE VIEW user_active_summary AS SELECT u.id, u.name, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' GROUP BY u.id, u.name;
哪些场景真正适合用视图
视图的价值不在“炫技”，而在降低重复成本和收敛访问逻辑：
权限隔离：给运营人员开放sales_report_view，只暴露
region、
month、
revenue字段，隐藏用户身份证、手机号等敏感列 查询复用：多个报表都需统计“近30天未登录用户”，抽成视图后，各业务方直接
SELECT * FROM inactive_users_30d，不用各自写
WHERE last_login兼容旧系统：表结构调整后（比如把
user_profile拆成
users+
profiles），建一个同名视图模拟旧表结构，避免下游应用改代码
视图性能差？先看执行计划再甩锅
很多人抱怨“视图慢”，其实问题几乎都出在底层查询本身。MySQL 不会对视图做额外优化——
EXPLAIN一个视图查询，看到的就是展开后的完整 SQL 执行计划。 不要在视图里写
SELECT *，尤其当基表有大字段（
TEXT、
BLOB）时，即使你只查其中一列，也可能拖慢整个链路 避免在视图定义中用
UNION ALL拼接多个大表，MySQL 8.0 前无法下推条件到各分支，导致全表扫描 如果视图常被用于过滤（如
WHERE status = 'active'），确保对应基表字段上有索引；视图本身无法建索引
复杂嵌套视图（A → B → C）会让执行计划难以追踪，调试成本陡增。生产环境建议控制在单层引用，或直接用 CTE 替代深层依赖。
