error 1142并非当前用户缺权限，而是sql security definer模式下mysql按definer账号身份校验基表select权：若definer不存在、被锁、密码过期或未被逐表授予基表select权限，即使当前用户权限完整，查询视图仍失败。
SQL SECURITY DEFINER 为什么会让 SELECT 报 ERROR 1142
不是当前用户缺权限，而是 MySQL 在执行视图/存储过程时，按 DEFINER 账号身份去查基表权限。哪怕你有 SELECT ON *.*，只要 DEFINER 账号不存在、被锁、密码过期，或没被授予某张基表的 SELECT 权限，就会报错。
常见现象：
- 视图能
SHOW CREATE VIEW出来，但一SELECT * FROM view_name就崩 -
SHOW GRANTS FOR CURRENT_USER()显示权限完整，却依然拒绝访问 - 错误码是
ERROR 1142（命令被拒绝）或ERROR 1449（definer 不存在）
怎么确认当前视图用了哪个 DEFINER 和 SECURITY 模式
直接查定义语句，别猜：
SHOW CREATE VIEW your_view\G
重点关注两行输出：
-
DEFINER=`xxx`@`yyy`—— 实际用来校验权限的账号 -
SQL SECURITY DEFINER（默认）或SQL SECURITY INVOKER
如果是 INVOKER，那才真正检查 CURRENT_USER() 的权限；DEFINER 模式下，CURRENT_USER() 的权限完全不参与校验。
验证 DEFINER 是否真实存在：
SELECT User, Host FROM mysql.user WHERE User = 'xxx' AND Host = 'yyy';
DEFINER 存在但权限不足，该怎么补
不能只给 GRANT SELECT ON mydb.* —— MySQL 是逐表校验的，database.* 不自动覆盖所有表。
必须显式授权每一张基表：
- 先查视图依赖哪些表：
SELECT TABLE_NAME FROM information_schema.VIEW_TABLE_USAGE WHERE VIEW_SCHEMA = 'db_name' AND VIEW_NAME = 'your_view'; - 对每张基表单独授
SELECT：GRANT SELECT ON mydb.table_a TO 'xxx'@'yyy'; - 如果涉及嵌套视图，
DEFINER还需SHOW VIEW权限 - 授权后务必执行：
FLUSH PRIVILEGES;
ALTER DEFINER 时容易踩的坑
改 DEFINER 不是随便换一个能登录的账号就行：
- 别硬写
'root'@'localhost'—— 容器或远程环境可能根本不存在这个账号 - 优先用
CURRENT_USER()动态替换：ALTER DEFINER = CURRENT_USER SQL SECURITY DEFINER VIEW your_view AS ...; - 确保新
DEFINER已解锁：ALTER USER 'xxx'@'yyy' ACCOUNT UNLOCK; - 如果
password_expired = 'Y'，必须先重置密码：ALTER USER 'xxx'@'yyy' PASSWORD EXPIRE NEVER;
最隐蔽的点：MySQL 8.0 启用角色后，DEFINER 用户即使有账号，也可能没激活角色——得确认 activate_all_roles_on_login 是否开启，或手动 SET ROLE ALL;。
