执行失败主因是DEFINER用户不存在、失效或权限不足，需先用SHOW CREATE PROCEDURE查DEFINER和SQL SECURITY类型，再验证用户存在性及对应权限；禁用直接改mysql.proc，须通过导出→替换→删除→重建流程修复。
直接结论：执行失败不是调用者缺 EXECUTE 权限，而是 DEFINER 用户不存在、密码失效或权限不全 —— 修复重点在定义者身份本身，不是改调用逻辑。
查清当前 DEFINER 和 SQL SECURITY 类型
别猜，先确认问题源头。执行：
SHOW CREATE PROCEDURE `proc_name`;
重点关注两处输出：
-
DEFINER=`some_user`@`host`—— 这个用户在目标库是否存在？ -
SQL SECURITY DEFINER（默认）或SQL SECURITY INVOKER—— 决定权限校验主体
若没显式写 SQL SECURITY，MySQL 就按 DEFINER 处理。用 SELECT User, Host FROM mysql.user WHERE User = 'some_user'; 验证用户存在性；若存在，再用 SHOW GRANTS FOR 'some_user'@'host'; 检查其是否拥有过程内所有 SQL 所需的最小权限（比如过程里 INSERT INTO stats.t_daily，就得有 INSERT ON stats.t_daily）。
DEFINER 用户缺失时的修复方式
不能直接 UPDATE mysql.proc 表（MySQL 5.7+ 只读，硬改会报错 ERROR 1294；云数据库如阿里云 RDS 更是完全禁写 mysql 库）。必须走安全重建流程：
- 用
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替换为一个已在目标库存在、且权限完备的运维账号（推荐'admin'@'%'或专用账号如'proc_runner'@'%'） - 先执行
DROP PROCEDURE IF EXISTS `proc_name`;清旧对象 - 再导入：
mysql -u root -p db_name
注意：如果过程内部调用了其他函数或过程，那些对象的 DEFINER 也得同步检查并修复，否则重建后首次调用仍会失败。
为什么不能简单改成 SQL SECURITY INVOKER？
INVOKER 看似省事，但只在特定场景真正可用：
- 调用者必须拥有过程体中每一条 SQL 的全部权限（包括
SELECT系统表如mysql.proc、performance_schema，MySQL 8.0+ 还要SYSTEM_VARIABLES_ADMIN） - 过程里显式写了
SELECT * FROM mysql.user，而调用者没被授SELECT ON mysql.*，就会直接报错Access denied - 业务逻辑依赖固定权限上下文（比如审计日志写入必须用高权限账号），
INVOKER会导致行为不一致
生产环境更推荐保持 SQL SECURITY DEFINER，只把 DEFINER 统一改为可控的专用账号，并严格授予其过程所需的最小权限集 —— 这样既稳定，又避免把权限扩散到每个调用者。
容易被忽略的嵌套与系统权限点
很多人修完主过程就以为完事了，结果运行时报错才意识到：
- 过程里
CALL another_proc()→another_proc的DEFINER也得存在且权限完整 - 过程读取
@@max_connections或@@version→ MySQL 8.0+ 必须给DEFINER授SYSTEM_VARIABLES_ADMIN - 过程创建临时表或写入日志库 →
DEFINER要有对应库的CREATE TEMPORARY TABLES或INSERT权限
DEFINER 不是单点问题，而是一条权限链。只要其中任意一环断裂，整个过程就会在运行时崩掉 —— 日志里往往只显示 “access denied”，不会告诉你具体卡在哪一层。
