缺CREATE VIEW权限需显式授予数据库级权限（如myapp_db.*），执行SHOW GRANTS确认存在该权限项，严格匹配host和database_name，授完必须FLUSH PRIVILEGES；嵌套视图还须确保源视图的SELECT和SHOW VIEW权限。
直接看权限列表，缺 CREATE VIEW 就是它
执行 SHOW GRANTS FOR 'username'@'host' 看有没有 CREATE VIEW
MySQL 不会因为你有 SELECT 或 ALL PRIVILEGES ON database.table 就自动给你视图权限。必须显式出现 CREATE VIEW 字样，且作用域是数据库级（比如 myapp_db.*），不是表级或全局级。
- 如果输出里只有
GRANT SELECT, INSERT ON `myapp_db`.`users` TO ...—— 权限太细，无效 - 如果压根没
CREATE VIEW，就是缺授权，不是语法或版本问题 - 用
SELECT USER(), CURRENT_USER();确认你连的是哪个 host 形式，'user'@'localhost'和'user'@'%'是两个不同账号
GRANT CREATE VIEW 时 host 和 database_name 写错会静默失败
MySQL 权限匹配是严格字符串比对，写错一个字符都不会生效。
-
database_name必须写成myapp_db.*，不能是myapp_db（少.*）或myapp_db.users（多了表名） -
host必须和CURRENT_USER()返回的一致，常见坑是用了'user'@'127.0.0.1'却连的是'user'@'localhost' - 授完权必须立刻执行
FLUSH PRIVILEGES;，否则内存里不加载新权限
基于已有视图建新视图时，ERROR 1349 往往不是缺 CREATE VIEW
这个错误表面是“view has errors”，实际常因依赖链权限断裂：你有 CREATE VIEW，但没被授予源视图的 SELECT 或 SHOW VIEW 权限。
- 先手动跑
SELECT * FROM existing_view LIMIT 1;，如果这步就报错，说明你连源视图都查不了 - 再跑
SHOW CREATE VIEW existing_view;，如果也报错，大概率缺SHOW VIEW权限（很多 GUI 工具会因此卡住，但命令行建视图仍可能成功） -
DEFINER属性会触发额外校验——如果源视图是SQL SECURITY DEFINER，MySQL 会以定义者身份去检查底层表权限，跟你当前用户无关
GUI 工具报错 ≠ 创建失败，别被界面误导
DBeaver、Navicat 这类工具在刷新视图列表或双击查看定义时，会自动发 SHOW CREATE VIEW。如果你没被授予 SHOW VIEW，工具就弹窗报错或显示空列表，但你手动写 CREATE VIEW v2 AS SELECT * FROM v1; 依然能成功——只要 CREATE VIEW 和源视图的 SELECT 权限都在。
真正容易被忽略的是：嵌套视图场景下，SHOW VIEW 和源视图的 SELECT 权限缺一不可，而这两项常被误认为“只读权限，不影响创建”。
