错误1449表示definer用户不存在，与调用者权限无关；错误1370是调用者缺execute权限或definer缺底层sql权限；错误1142是调用者或definer缺select on mysql.proc权限。
先确认报错是哪一类权限问题
看到“权限不足”别急着加 GRANT EXECUTE，先看错误码：
-
ERROR 1449 (HY000)：DEFINER 用户不存在，比如The user specified as a definer ('olduser'@'192.168.1.%') does not exist—— 这是迁移或用户清理后最常见的情况，和调用者权限完全无关 -
ERROR 1370 (42000)：调用者缺EXECUTE权限，或者 DEFINER 用户存在但缺过程内某条 SQL 所需的底层权限（如INSERT ON other_db.t_log） -
ERROR 1142 (42000)：调用者或 DEFINER 缺SELECT ON mysql.proc（MySQL 5.7/8.0 兼容层仍依赖该表读元数据）
SHOW CREATE PROCEDURE proc_name; 立刻能区分主因：看有没有 DEFINER 字段、是否显式写了 SQL SECURITY INVOKER。
查清当前会话实际认证身份
很多人授了权却无效，是因为连的根本不是自己以为的那个账号。执行：
SELECT USER(), CURRENT_USER();
-
USER()是你声明的身份（比如'app'@'127.0.0.1'） -
CURRENT_USER()才是 MySQL 实际匹配并鉴权的账号（可能是'app'@'%'或'app'@'localhost'）
SHOW GRANTS FOR CURRENT_USER();
输出里必须包含类似这一行才算 EXECUTE 生效：GRANT EXECUTE ON PROCEDURE `mydb`.`my_proc` TO 'app'@'%'
DEFINER 用户缺失或失效时怎么修
不能直接 UPDATE mysql.proc —— MySQL 5.7+ 系统表只读，云数据库（如阿里云 RDS）甚至禁止写入 mysql 库。正确流程是：
- 导出：
mysqldump -u root -p --routines --no-create-info --no-data --skip-opt mydb > procs.sql - 替换 DEFINER：
sed -i "s/DEFINER=\`olduser\`@.\+/DEFINER=\`admin\`@'%'/g" procs.sql（确保admin用户已存在且权限完备） - 删旧过程：
DROP PROCEDURE IF EXISTS `my_proc`; - 重载：
mysql -u root -p mydb
DEFINER 也得同步检查并替换，否则重建后首次调用仍失败。
为什么改 SQL SECURITY INVOKER 常常不现实
听起来简单——把过程改成 SQL SECURITY INVOKER，让调用者权限生效。但实际踩坑点很多：
- 调用者必须拥有过程里每一条 SQL 的全部权限，包括
SELECT ON mysql.proc（否则连定义都读不到）、INSERT INTO audit.log、甚至SELECT FROM performance_schema.events_statements_summary_by_digest（MySQL 8.0+ 默认拒绝） - 过程里显式查了
mysql.user表，而业务账号没被授SELECT ON mysql.user，就会直接报错 - 审计日志写入、跨库写表等逻辑依赖固定高权限上下文，换成 INVOKER 后行为不可控
SQL SECURITY DEFINER，只把 DEFINER 统一改为专用运维账号（如 'proc_runner'@'%'），并严格授予其最小必要权限。
