直接结论：执行失败主因是definer用户不存在、失效或权限不足，而非调用者缺execute权限；须先用show create procedure查definer和sql security类型，再验证用户存在性及对应权限，修复必须通过导出→替换→删除→重建流程，禁用直接改mysql.proc。
直接看 DEFINER 用户是否存在、权限是否匹配，而不是查调用者有没有 EXECUTE 权限——后者只决定“能不能调”，不决定“调了能不能跑通”。
查清当前 DEFINER 和 SQL SECURITY 类型
别靠猜测，先执行：SHOW CREATE PROCEDURE `proc_name`;
重点关注两处：
• DEFINER=`some_user`@`host` —— 这个账号在 mysql.user 表里是否存在？
• SQL SECURITY DEFINER（默认）还是 SQL SECURITY INVOKER —— 前者走定义者权限校验，后者才看调用者权限。
验证账号存在性：SELECT User, Host FROM mysql.user WHERE User = 'some_user';
再确认 host 是否完全一致（'u'@'localhost' 和 'u'@'%' 是两个独立账号）。
DEFINER 用户缺失或失效时必须重建过程
不能改 mysql.proc 表（5.7+ 只读，RDS 等云库直接禁止写），也不能用 ALTER PROCEDURE 改 DEFINER（MySQL 8.0.16 前不支持）。唯一安全路径是重建：
• 先导出定义：mysqldump -u root -p --routines --no-create-info --no-data db_name > procs.sql
• 用 sed 或编辑器替换 DEFINER=`old`@`host` 为一个已存在、权限完备的专用账号（如 'proc_runner'@'localhost'）
• 执行：DROP PROCEDURE IF EXISTS `proc_name`;，再导入新定义
注意：如果过程内部调用了其他函数或过程，那些对象的 DEFINER 也得同步检查，否则首次调用仍会失败。
DEFINER 权限不全但用户存在时的修复要点
现象是能 CALL 成功，但执行到某条 SQL 就报 Access denied（比如 SELECT * FROM app_db.orders）。这是因为 MySQL 只校验 DEFINER 对静态 SQL 涉及对象的权限，不检查调用者。
修复步骤：
• 查 DEFINER 当前权限：SHOW GRANTS FOR 'definer_user'@'host';
• 显式授予过程内所有静态 SQL 所需权限，例如：GRANT SELECT, INSERT ON app_db.orders TO 'definer_user'@'host';
• 注意 host 必须精确匹配，且动态 SQL（PREPARE+EXECUTE）不走 DEFINER 校验，仍按调用者权限检查，这点容易被忽略。
为什么不能简单改成 SQL SECURITY INVOKER？
看似绕过 DEFINER 问题，但实际限制更严：
• 调用者必须拥有过程体内每一条 SQL 的全部权限，包括查 mysql.proc、performance_schema 等系统表（MySQL 8.0+ 还要 SYSTEM_VARIABLES_ADMIN）
• 如果过程里写了 SELECT * FROM mysql.user，而调用者没被授 SELECT ON mysql.*，立刻报错
• 业务逻辑依赖固定权限上下文（比如审计日志写入必须用高权限账号），INVOKER 会导致行为不可控
生产环境更推荐保持 SQL SECURITY DEFINER，只把 DEFINER 统一换成可控的专用低权账号，并严格授最小必要权限。
