视图本质是命名的select语句，不存储数据也不提升性能，仅解决sql复用与封装；优化关键在于底层查询、基表索引及条件下推，而非视图本身。
直接结论：视图能把你写过三遍以上的多表 JOIN 抽出来重用，但不会自动变快——它只是把那堆 SELECT + JOIN + ON 语句存成一个名字，查的时候照样实时执行。
CREATE VIEW 必须显式指定 DEFINER 和 SQL SECURITY
不设这两项，导出再导入、或换账号执行时，大概率报 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。MySQL 默认用当前登录用户当 DEFINER，而该用户在目标库往往不存在。
- 推荐写法：
CREATE SQL SECURITY DEFINER DEFINER = 'admin'@'localhost' VIEW v_user_orders AS ... -
SQL SECURITY DEFINER表示以定义者权限运行（适合多数业务）；SQL SECURITY INVOKER按调用者权限查（需精细控制时才用） - 不确定时，用
DEFINER = CURRENT_USER固化当前用户，避免迁移后失效
ALGORITHM=MERGE 还是 TEMPTABLE？选错直接影响可更新性和性能
ALGORITHM=MERGE 把视图 SQL 和外部查询合并重写，能走基表索引，满足条件时支持 UPDATE/DELETE；ALGORITHM=TEMPTABLE 先物化结果到临时表，无法更新，且丢失索引能力——但支持 GROUP BY、DISTINCT、子查询等复杂逻辑。
- 高频关联查询（如订单+用户+商品）优先强制写
ALGORITHM=MERGE，别依赖UNDEFINED自动推断 - 含聚合或去重的报表类视图，才考虑
ALGORITHM=TEMPTABLE - MySQL 8.0+ 对
MERGE的下推优化更成熟，但一旦视图里出现函数、子查询或ORDER BY（没配LIMIT），就会自动降级为TEMPTABLE
哪些写法会让 CREATE VIEW 直接失败
视图不是任意 SELECT 都能塞进去。MySQL 对语法有硬性限制：
- 不能含用户变量：
@row := @row + 1→ 报错 - 不能引用临时表：
FROM temp_session→ 报错（临时表对视图不可见） - 不能单独带
ORDER BY：SELECT * FROM orders ORDER BY created_at→ 报错；必须加LIMIT（如ORDER BY created_at LIMIT 9223372036854775807）或干脆去掉，排序交给上层 - 不能含
FOR UPDATE、LOCK IN SHARE MODE等锁语句 - 字段名冲突必须用
AS显式别名，否则ERROR 1060 (42S21): Duplicate column name 'id'
为什么视图查得慢，但 EXPLAIN 看不出问题
因为视图本身不存执行计划，EXPLAIN SELECT * FROM v_user_orders 展开的是整个嵌套逻辑——你看到的是最终合并后的执行树，它掩盖了中间哪张表没走索引、哪个 JOIN 顺序不合理。
- 真正要优化，得把视图定义里的原始
SELECT拿出来单独EXPLAIN - 重点检查每个
ON字段是否有索引，尤其是多表关联链末端（比如order_items.order_id） - 别指望谓词自动下推：视图里没写
WHERE user_id = ?，外部加了也不一定生效，可能先算全量再过滤
最常被忽略的点是：视图不解决性能问题，只解决复用和封装问题。如果你发现视图查得慢，第一反应不该是“怎么优化视图”，而是“原始 SQL 有没有索引、JOIN 顺序是否合理、WHERE 条件能不能下推”。
