视图是保存的SELECT语句，用于封装多表JOIN和子查询，提供单表查询体验；创建时需显式指定DEFINER和SQL SECURITY以避免权限错误；支持ALGORITHM=MERGE（合并优化）或TEMPTABLE（物化）；有变量、临时表、ORDER BY等限制；更新需满足可更新性约束；无缓存与索引，性能取决于底层表。
视图能帮你把多表 JOIN 和子查询“封装”起来
视图不是临时表，也不是物化结果，它是一条保存的 SELECT 语句。当你频繁写类似 SELECT u.name, o.total, p.title FROM users u JOIN orders o ON u.id = o.user_id JOIN products p ON o.product_id = p.id WHERE o.status = 'paid' 这种三表关联查询时，用视图能把这段逻辑固化为一个虚拟表名，比如 v_paid_orders_with_product，后续直接 SELECT * FROM v_paid_orders_with_product 就行——本质上是把嵌套逻辑“扁平化”成单表查询感。
创建视图时别漏掉 DEFINER 和 SQL SECURITY
MySQL 默认用当前用户作为 DEFINER，但如果你导出视图再导入到另一台服务器，或用不同账号执行查询，可能因权限不匹配报错 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。更稳妥的做法是显式指定：
CREATE ALGORITHM=MERGE SQL SECURITY DEFINER VIEW v_active_users AS SELECT id, name, email FROM users WHERE status = 'active';
注意：ALGORITHM=MERGE 表示查询时会把视图定义和外部查询合并优化（适合简单 SELECT），而 ALGORITHM=TEMPTABLE 会先物化结果（支持 GROUP BY、聚合等，但无法更新）；多数简化嵌套场景用 MERGE 更高效。
视图里不能有变量、不能引用临时表、不能含 ORDER BY（除非配合 LIMIT）
这些限制会让一些“直觉上该能用”的写法直接失败：
-
SELECT @row := @row + 1 AS row_num, ...→ 报错：视图中不允许用户变量 -
SELECT * FROM temp_session JOIN v_user_orders→ 报错：临时表对视图不可见 -
SELECT * FROM orders ORDER BY created_at DESC→ 单独建视图会报错，必须写成ORDER BY created_at DESC LIMIT 9223372036854775807（或干脆去掉，把排序交给上层查询）
真正需要排序或分页的逻辑，应该放在查视图的外部语句里，比如 SELECT * FROM v_user_orders ORDER BY order_date DESC LIMIT 20。
更新视图要满足“可更新性”硬约束
如果目标是让 UPDATE v_user_orders SET status = 'shipped' 生效，视图必须满足：单表来源、无聚合函数、无 DISTINCT、无子查询、所有列非计算列且有明确基表映射。一旦用了 JOIN 或 GROUP BY，视图就变成只读——这不是 bug，是 MySQL 的设计选择。
常见踩坑点：
- 视图字段起别名（如
u.name AS user_name）不影响更新，但若别名掩盖了原始列名（如MAX(o.amount) AS amount），该列就不可更新 - 即使视图只查一张表，如果加了
WHERE条件过滤掉某些行，UPDATE 仍可能成功，但实际影响行数可能为 0（被 WHERE 挡住了） - 用
INSERT INTO v_active_users插入数据时，MySQL 会检查插入值是否满足视图的WHERE status = 'active'，不满足则报错
复杂嵌套查询封装进视图后，最常被忽略的是它的“透明性”——它不缓存、不索引、不改变执行计划。性能瓶颈依然在底层表和关联条件上，别指望建个视图就能自动加速。
