MySQL 8.4存储过程权限校验失败主因是DEFINER用户缺失或SQL SECURITY模式不匹配，需用SHOW CREATE PROCEDURE查定义，验证DEFINER账号存在性、权限及账户状态，并通过导出→替换→删除→重建流程修复，禁直接修改系统表。
MySQL 8.4 存储过程权限校验失败，90% 是 DEFINER 用户缺失或 SQL SECURITY 模式不匹配导致的，不是调用者缺 EXECUTE 权限。
查清 DEFINER 和 SQL SECURITY 设置
执行 SHOW CREATE PROCEDURE `proc_name`;，重点看两行：
-
DEFINER=`user`@`host`—— 这个账号在当前实例的mysql.user表里是否存在？注意host必须完全一致（'admin'@'localhost'和'admin'@'127.0.0.1'是两个不同账号） -
SQL SECURITY DEFINER或SQL SECURITY INVOKER—— MySQL 8.4 默认仍是DEFINER；若没显式声明，就按DEFINER处理
别跳过这步直接授权。很多问题根源就在这里：你 GRANT 了 EXECUTE，但过程根本加载失败，压根没走到执行阶段。
确认 DEFINER 用户真实可用
运行以下命令验证：
-
SELECT User, Host FROM mysql.user WHERE User = 'user' AND Host = 'host';（替换为实际值） -
SHOW GRANTS FOR 'user'@'host';—— 确保它有过程内所有操作所需的最小权限（比如过程里写INSERT INTO log.t，就得有INSERT ON log.t） -
SELECT authentication_string, account_locked FROM mysql.user WHERE User = 'user' AND Host = 'host';—— 检查是否被锁、密码是否为空或加密方式不兼容（MySQL 8.4 默认用caching_sha2_password）
云数据库（如阿里云 RDS 8.4）通常禁用 root 账号，DEFINER 若设为 'root'@'%'，几乎必挂。
修复 DEFINER 缺失必须重建，不能改 mysql.proc
MySQL 8.4 的 mysql.proc 表已彻底移除（由 mysql.routines 和 mysql.parameters 替代），且系统库只读。硬改会报错 ERROR 1294 或拒绝连接。
安全重建流程：
- 导出：
mysqldump -u root -p --routines --no-create-info --no-data --skip-opt mydb > procs.sql - 替换 DEFINER：
sed -i "s/DEFINER=`old`@`%`/DEFINER=`proc_runner`@`%`/g" procs.sql（推荐专用低权限账号，如'proc_runner'@'%'） - 清理：
DROP PROCEDURE IF EXISTS `proc_name`; - 重载：
mysql -u root -p mydb
注意：如果过程内部调用了函数或其他过程，它们的 DEFINER 也得一并检查和替换，否则首次调用仍失败。
调用者还得有 SELECT ON mysql.routines
MySQL 8.4 不再依赖 mysql.proc，但会从 mysql.routines 读取元数据。若调用者没有该表的 SELECT 权限，过程甚至无法解析定义，报错可能是模糊的 ERROR 1142 或静默失败。
确认方式：SHOW GRANTS FOR CURRENT_USER();，输出中必须含：
GRANT SELECT ON `mysql`.`routines` TO `your_user`@`%`
若无，用高权限账号执行：GRANT SELECT ON mysql.routines TO 'your_user'@'%';
这个点最容易被忽略——你修好了 DEFINER，也给了 EXECUTE，但过程连定义都读不出来。
