视图访问失败时典型错误是error 1449 (hy000): the user specified as a definer ('user_name'@'host') does not exist，表明定义者账户已被删除，导致mysql执行时无法校验权限。
因为视图的 DEFINER 账户被删了，MySQL 在执行时找不到这个「定义者」，直接报错拒绝访问。
视图访问失败时典型的错误信息是什么？
你执行 SELECT * FROM xxx_view 时，大概率会看到：
ERROR 1449 (HY000): The user specified as a definer ('user_name'@'host') does not exist
或者更隐蔽一点的：
ERROR 1356 (HY000): View 'db.vw' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
- 前者明确告诉你：定义者账号不存在 —— 这就是删用户后最常见、最直接的表现
- 后者范围更广，但只要查过
SHOW CREATE VIEW vw发现DEFINER指向一个已删除的user@host，基本可以锁定根因
为什么删用户会影响视图，但不影响普通表权限？
普通表权限记录在 mysql.tables_priv 或 mysql.db 表里，跟当前登录用户绑定；而视图（以及存储过程、函数）的 DEFINER 是固化在对象元数据里的，属于「创建快照」——它不随用户授权变化而更新，也不会自动 fallback 到调用者。
-
SQL SECURITY DEFINER（默认值）意味着：执行时以DEFINER身份检查权限，不是以当前登录用户身份 - 哪怕新用户有
ALL PRIVILEGES ON db.*，只要DEFINER账户物理不存在，就卡在权限校验第一关 - 注意：
SQL SECURITY INVOKER可绕过这个问题，但它要求调用者自己拥有底层表的所有必要权限，适用场景有限
怎么快速修复被“ orphaned ”的视图？
核心思路是重写视图的 DEFINER，让它指向一个真实存在且有足够权限的账户（比如 root@localhost 或当前运维账号）。
- 先确认当前视图定义：
SHOW CREATE VIEW your_view_name\G - 复制
Create View:后面整条语句，把开头的CREATE ALGORITHM=...改成CREATE OR REPLACE ALGORITHM=... - 手动替换
DEFINER=`old_user`@`old_host`为DEFINER=`new_user`@`localhost`（注意引号和反引号） - 执行修改后的语句 ——
CREATE OR REPLACE VIEW会原地更新，不丢权限、不中断依赖
如果要批量处理，可以用如下 SQL 生成修复语句（需在 mysql 系统库中运行）：
SELECT CONCAT('CREATE OR REPLACE VIEW `', table_schema, '`.`', table_name, '` AS ', view_definition, ';')
FROM information_schema.views
WHERE definer = '''old_user''@''%'''
AND table_schema = 'your_db';
容易被忽略的关键细节
账户名是 user@host 的完整组合，'user'@'%' 和 'user'@'192.168.1.100' 是两个完全不同的账户。安全加固时把 % 改成具体 IP，本质就是删掉了旧账户、新建了新账户 —— 视图的 DEFINER 不会自动迁移，这点在 TDSQL、MariaDB、MySQL 全系都一样。
