MySQL 8.0.16+支持GRANT EXECUTE ON PROCEDURE语法，但须先授USAGE权限；5.7及更早版本不识别该语法，会报ERROR 1064；最兼容做法是GRANT EXECUTE ON db.*。
直接给用户授 EXECUTE 权限即可调用存储过程或函数，但必须明确作用范围——不是“授给过程名”，而是“授给数据库或具体过程对象”。
GRANT EXECUTE ON PROCEDURE 语法是否可用？
取决于 MySQL 版本：
- MySQL 5.7 及更早版本：
GRANT EXECUTE ON PROCEDURE db.proc_name会报错ERROR 1064 (42000)，语法不被识别 - MySQL 8.0.16+：支持该语法，但必须先授予
USAGE权限，否则直接失败：GRANT USAGE ON `db`.* TO 'u'@'%' - 无论哪个版本，
GRANT EXECUTE ON db.*都有效，且是最常用、最兼容的做法
为什么 CALL 还报 “EXECUTE command denied”？
常见原因不是没授权，而是权限路径或执行上下文不匹配：
- 用户连接 host 和授权 host 不一致，比如授的是
'user'@'localhost'，但应用连的是'user'@'127.0.0.1'（MySQL 视为两个不同账号） - 过程定义在
otherdb，你却只对mydb授了EXECUTE，跨库调用时目标库也得授 - 过程内部查了
otherdb.table，但用户没有otherdb的SELECT权限；即使SQL SECURITY DEFINER，若定义者账号不可用（如已删），也会 fallback 到调用者权限校验 - 过程用了动态 SQL（
PREPARE/EXECUTE），MySQL 会按调用者权限检查语句中涉及的表，此时SQL SECURITY INVOKER才真正生效
如何最小化授权范围？
MySQL 原生不支持“只让调用某几个过程”，但可通过结构设计逼近目标：
- 把要开放的过程统一放到专用库（如
api_routines），只对该库授EXECUTE：GRANT EXECUTE ON `api_routines`.* TO 'appuser'@'%' - 避免用
GRANT EXECUTE ON *.*—— 全局授权风险高，且无法撤销单个过程权限 - 不要依赖角色（role）做细粒度控制：MySQL 角色同样只能绑定到库级
EXECUTE，无法按对象名过滤 - 如果业务真需要白名单式调用控制，应在应用层或代理层（如 ProxySQL）拦截，而不是在 MySQL 权限层硬凑
最容易被忽略的一点是：EXECUTE 权限本身不解决过程内部的表访问问题。哪怕语法、对象、host 全对，只要过程里一条 SELECT 缺权限，MySQL 就统一报 EXECUTE command denied，不会告诉你具体哪张表卡住——得靠 SHOW CREATE PROCEDURE 和 INFORMATION_SCHEMA.ROUTINES 交叉验证定义者和安全上下文。
