必须显式指定DEFINER和SQL SECURITY，否则跨环境部署易因定义者用户不存在而报ERROR 1449；推荐DEFINER='admin'@'localhost'且SQL SECURITY DEFINER，并优先使用ALGORITHM=MERGE以支持索引与更新。
CREATE VIEW 时必须显式指定 DEFINER 和 SQL SECURITY
不加这两项，导出再导入、换账号查、跨环境部署时大概率报 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。MySQL 默认用当前登录用户当 DEFINER，但这个用户在目标库很可能不存在。
- 稳妥写法是固定一个有权限的账号，比如
DEFINER='admin'@'localhost' -
SQL SECURITY DEFINER表示按定义者权限执行（推荐），SQL SECURITY INVOKER则按调用者权限——后者容易因调用者缺权限而失败 - 如果拿不准，统一加上
SQL SECURITY DEFINER就行
优先用 ALGORITHM=MERGE，别默认依赖 TEMPTABLE
ALGORITHM=MERGE 让 MySQL 把视图定义和外部查询合并优化，能走索引、支持更新；ALGORITHM=TEMPTABLE 会先物化结果到临时表，失去索引能力，且无法更新。多数简化嵌套场景都该用 MERGE。
- MERGE 不是强制保证：MySQL 在遇到聚合、GROUP BY、子查询等时会自动降级为 TEMPTABLE，执行计划里出现
derived表就是信号 - 建视图时不写
ALGORITHM，MySQL 会自己选，但你没法控制——显式写出来更可控 - 想确认是否生效？查
SHOW CREATE VIEW v_name，看输出里明确写了什么
视图里不能写 ORDER BY、LIMIT、变量或临时表
这些不是“语法错误”，而是 MySQL 强制限制。视图本质是可复用的查询模板，排序、分页、状态变量这些逻辑应该交给上层决定。
-
ORDER BY created_at DESC单独写在视图里会直接报错；非要通过语法检查，得写成ORDER BY created_at DESC LIMIT 9223372036854775807，但毫无意义 -
SELECT @row := @row + 1 AS row_num这类变量赋值，在视图中直接失败 - 视图里引用
temp_session这种会话级临时表，查的时候提示“表不存在”——临时表对视图不可见 - 真要排序分页？在外面查：
SELECT * FROM v_user_orders ORDER BY order_date DESC LIMIT 20
UPDATE 视图前先验证可更新性约束
不是所有视图都能 UPDATE 或 DELETE。想让 UPDATE v_paid_orders SET status = 'shipped' 生效，必须同时满足：
- 只查一个基表（不能有
JOIN） - 不含聚合函数（
COUNT、AVG等）、DISTINCT、子查询、UNION - 所有列都是基表字段的直接映射，不能是计算列（如
price * quantity AS amount） - 没有
WHERE条件过滤掉部分行（否则无法确定唯一目标行）
最常被忽略的是 JOIN 和 WHERE ——哪怕只是 LEFT JOIN 或带过滤条件的单表视图，基本就丧失可更新性了。
