MySQL不支持精确到单个存储过程的权限撤销，8.0.16+才支持GRANT EXECUTE ON PROCEDURE语法且需先授USAGE；报“EXECUTE command denied”主因是过程内表权限缺失或DEFINER失效，而非EXECUTE未授权。
不能直接“精确”到单个存储过程或函数——MySQL原生不支持按routine名撤销或隔离执行权限，所谓“精确”只能靠版本适配+库级隔离+SQL SECURITY配合实现。
GRANT EXECUTE ON PROCEDURE 语法到底能不能用
取决于 MySQL 版本：
- MySQL 5.7 及更早：直接报
ERROR 1064 (42000)，语法不识别，必须用GRANT EXECUTE ON db.* - MySQL 8.0.16+：支持
GRANT EXECUTE ON PROCEDURE db.proc_name，但必须先执行GRANT USAGE ON `db`.* TO 'u'@'%'，否则失败 - 无论哪个版本，
GRANT EXECUTE ON db.*都有效，且是线上最常用、兼容性最好的写法
为什么 CALL 还报 “EXECUTE command denied”
这个错误几乎从不表示“没授 EXECUTE 权限”，而是暴露了更深层的权限链断裂：
- 用户连接 host 和授权 host 不一致，例如授的是
'u'@'localhost'，但应用连的是'u'@'127.0.0.1'（MySQL 视为两个账号） - 过程定义在
otherdb，你只对mydb授了 EXECUTE，跨库调用时目标库也得授 - 过程内部查了
otherdb.table，但用户没有otherdb的SELECT权限；即使SQL SECURITY DEFINER，若定义者账号已删，会 fallback 到调用者权限校验 - 过程用了动态 SQL（
PREPARE/EXECUTE），MySQL 按调用者权限检查语句中涉及的表，此时SQL SECURITY INVOKER才真正生效
如何逼近“只允许调用某几个过程”的效果
MySQL 没有白名单式 routine 级权限控制，但可通过结构设计压缩攻击面：
- 把要开放的过程统一放到专用库（如
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 mydb.my_proc查看DEFINER和SQL SECURITY设置 -
SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'mydb'交叉验证定义者和安全上下文 - 确认过程内所有 DML 涉及的表，都显式授予对应权限（如
GRANT SELECT ON mydb.logs TO 'user'@'%'）
