MySQL 8.4存储过程执行失败主因是DEFINER用户不存在、失效或权限不全，需先用SHOW CREATE PROCEDURE查DEFINER和SQL SECURITY，再验证用户存在性、权限及账户状态，最后通过导出→替换→删除→重建修复。
报错不是调用者缺 EXECUTE 权限，而是 DEFINER 用户不存在、失效或权限不全 —— 排查必须从 SHOW CREATE PROCEDURE 开始，跳过这步直接授权等于白忙。
怎么看存储过程的 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处理
别信“我导出时带了用户”，迁移后 mysql.user 表通常没同步，DEFINER 很可能根本不存在。错误码 ERROR 1449 就是典型信号。
怎么验证 DEFINER 用户是否真实可用
用高权限账号运行以下三条命令，缺一不可：
-
SELECT User, Host FROM mysql.user WHERE User = 'user' AND Host = 'host';—— 确认账号存在 -
SHOW GRANTS FOR 'user'@'host';—— 检查它是否有过程内每条 SQL 所需的最小权限（比如过程里写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）禁用 root 账号，若 DEFINER 设为 'root'@'%'，基本必挂。
为什么给了 EXECUTE 还是报错？别漏掉 mysql.proc 查询权
MySQL 在加载过程时需要读取元数据，调用者必须有 SELECT ON mysql.proc（MySQL 8.0+ 兼容层仍走此路径）。现象是：执行前就失败，错误可能是 ERROR 1142 或静默拒绝。
- 用
SHOW GRANTS FOR CURRENT_USER();确认输出中是否含GRANT SELECT ON `mysql`.`proc` TO ... - 没有就补：
GRANT SELECT ON mysql.proc TO 'your_user'@'%'; - 注意：这个权限常被忽略，尤其在只授
EXECUTE的自动化脚本里
过程内部若调用了其他函数或过程，那些对象的 DEFINER 也得同步检查 —— 否则重建后首次调用仍会失败。
修复必须重建，不能改系统表
MySQL 8.4 的 mysql.proc 表已移除，mysql.routines 只读，硬改会报 ERROR 1294 或拒绝连接。安全流程只有四步：
- 导出：
mysqldump -u root -p --routines --no-create-info --no-data --skip-opt db_name > procs.sql - 替换：
sed -i 's/DEFINER=`old_user`@`%`/DEFINER=`admin`@`%`/g' procs.sql（推荐用专用运维账号） - 清理：
DROP PROCEDURE IF EXISTS `proc_name`; - 重载：
mysql -u root -p db_name
最易被忽略的是：过程里涉及跨库操作（比如查 other_db.t1），DEFINER 必须有对应库表的显式权限，不能靠 GRANT ALL ON *.* 蒙混 —— MySQL 权限校验是逐对象、逐语句匹配的。
