用户需授予execute权限才能调用存储过程，而非create routine；授权格式为grant execute on procedure db_name.proc_name to 'user'@'host'；definer权限上下文不匹配或动态sql涉及表权限缺失也会导致“execute command denied”错误。
如何给用户授予存储过程执行权限
MySQL 中存储过程的执行权限（EXECUTE）和定义权限（CREATE ROUTINE）是分开控制的。想让某个用户能调用已存在的存储过程，只需授 EXECUTE 权限，不需要给 CREATE ROUTINE 或更宽泛的 ALTER ROUTINE。
常见错误是直接授 ALL PRIVILEGES，结果把数据库结构修改权也放出去了；或者误以为“创建过存储过程就自动有执行权”，其实创建者默认也不一定有执行权（取决于 sql_mode 和 definer 设置）。
- 对单个存储过程授权：
GRANT EXECUTE ON PROCEDURE `db_name`.`proc_name` TO 'user'@'host';
- 对整个库下所有存储过程授权：
GRANT EXECUTE ON PROCEDURE `db_name`.* TO 'user'@'host';
- 执行完记得刷新：
FLUSH PRIVILEGES;
（仅在直接操作mysql.proc表等非常规方式后才必须；常规GRANT语句会自动生效）
为什么调用时报错 “EXECUTE command denied”
这个错误不一定是没授 EXECUTE 权限——更常被忽略的是存储过程的 DEFINER 属性和当前用户的权限上下文不匹配。
比如一个过程定义为 DEFINER='root'@'localhost'，但当前用户没有 SELECT 权限访问它内部查询的某张表，MySQL 仍会报 EXECUTE command denied，而不是更具体的表权限错误。
- 查过程定义：
SHOW CREATE PROCEDURE `db_name`.`proc_name`;
看DEFINER是谁 - 如果
DEFINER是高权限账号，而调用者权限不足，可改用SQL SECURITY INVOKER创建（或重建）过程，让它以调用者身份检查权限 - 注意：修改
DEFINER需要SET USER权限，普通用户通常没有，得由 DBA 操作
CREATE ROUTINE 权限到底管什么
CREATE ROUTINE 只控制能否创建/修改/删除存储过程和函数，跟执行完全无关。它常被误当成“执行权”的前置条件，其实不是。
典型场景：DBA 给开发账号开 CREATE ROUTINE，让他们在测试库建过程；但上线后生产账号只给 EXECUTE，不给 CREATE ROUTINE，防止误删改逻辑。
- 授予定义权限：
GRANT CREATE ROUTINE ON `db_name`.* TO 'dev_user'@'%';
- 注意：启用该权限需先打开全局变量：
log_bin_trust_function_creators = 1（尤其在 binlog 开启时，否则连创建都会被拒） - 该权限本身不包含
EXECUTE，开发建完过程后，自己调用前仍需显式授权
权限变更后执行还是失败？检查这几点
授完权立刻试，却仍报错，大概率卡在细节上：
- 用户名和 host 必须完全匹配，
'user'@'127.0.0.1'和'user'@'localhost'是两个不同账号 - 存储过程名带库名时，授权语句里的库名必须和实际一致（大小写敏感取决于文件系统）
- 如果过程里用了动态 SQL（
PREPARE/EXECUTE），调用者还需对动态语句涉及的表有对应权限（如SELECT），不是只靠EXECUTE就够 - MySQL 8.0+ 引入角色（roles），如果权限是通过角色授予的，确认该角色已
SET DEFAULT ROLE给用户
最麻烦的其实是 DEFINER + 权限链 + 动态 SQL 的组合，这时候光看报错信息根本看不出缺哪一环，得一层层查过程定义、调用链、涉及表权限。
