MySQL 8.0.16+才支持GRANT EXECUTE ON PROCEDURE语法，5.7及更早版本执行即报ERROR 1064；必须先授USAGE权限且过程名须带库名，缺一不可。
确认 MySQL 版本是否支持 GRANT EXECUTE ON PROCEDURE
MySQL 5.7 及更早版本不识别该语法，执行会直接报 ERROR 1064 (42000)；只有 8.0.16+ 才真正支持对单个过程授 EXECUTE 权限。必须先运行：
SELECT VERSION();
若返回值低于 8.0.16，只能退而求其次：用 GRANT EXECUTE ON mydb.* TO 'user'@'%' 授权整个库的所有 routine。
常见误判点：
- 看到
SHOW GRANTS里有EXECUTE就以为 OK —— 实际可能是旧版本下靠GRANT ALL或GRANT EXECUTE ON mydb.*混过去的，不代表单过程语法可用 - 用 Docker 镜像或云数据库时，默认版本可能仍是 8.0.15（如某些阿里云 RDS 旧实例），需手动确认
GRANT EXECUTE ON PROCEDURE 必须搭配 USAGE 才生效
这是静默失败的高发区：语句能执行、不报错，但后续 CALL 仍报 ERROR 1370。缺一不可的两步是：
-
GRANT USAGE ON `mydb`.* TO 'appuser'@'%';（注意反引号包裹库名，mydb.*不能简写为mydb或mydb.%） -
GRANT EXECUTE ON PROCEDURE mydb.calc_score TO 'appuser'@'%';（过程名必须带库名，calc_score单独写非法）
通配符不支持：GRANT EXECUTE ON PROCEDURE mydb.* 会报错，这不是合法语法。
CALL 报 ERROR 1370 的真实原因往往不是没授权
这个错误提示极具误导性，90% 以上的情况和 EXECUTE 授权本身无关，而是运行时权限校验失败。重点排查：
- 检查过程定义：
SHOW CREATE PROCEDURE mydb.calc_score;看DEFINER字段是否指向一个仍存在的账号（如'dba'@'localhost'）。若该账号已被删或权限不足，MySQL 会 fallback 到调用者权限，此时哪怕EXECUTE授权成功，过程内一句SELECT otherdb.users也会因appuser缺otherdb的SELECT权限而失败 - 连接 host 不匹配：授权是
'appuser'@'10.0.1.%'，但应用连的是'appuser'@'localhost'—— MySQL 视为两个独立账号，权限不共享 - 过程用了动态 SQL（
PREPARE/EXECUTE），MySQL 会按调用者权限检查语句中涉及的表，此时SQL SECURITY INVOKER才真正生效
想真正限制“只允许调用某几个过程”，得绕开原生权限设计
MySQL 原生不支持白名单式的过程级控制。即使你显式执行了：
REVOKE EXECUTE ON PROCEDURE mydb.sp_x FROM 'u'@'%';
只要用户仍有 mydb.* 的 EXECUTE 权限，CALL mydb.sp_x() 依然能成功 —— 这不是 bug，是设计逻辑。
可行路径只有两条：
- 把要开放的过程统一挪到专用库（如
api_routines），只对该库授GRANT EXECUTE ON `api_routines`.* TO 'appuser'@'%'，再严格管控该库内只放白名单过程 - 在应用层或代理层（如 ProxySQL）拦截
CALL语句，做字符串匹配或路由规则，MySQL 权限层只做兜底
最容易被忽略的一点是：EXECUTE 权限本身不解决过程内部的表访问问题。哪怕语法、对象、host 全对，只要过程里一条 SELECT 缺权限，MySQL 就统一报 EXECUTE command denied，不会告诉你具体哪张表卡住——得靠 SHOW CREATE PROCEDURE 和 INFORMATION_SCHEMA.ROUTINES 交叉验证定义者和安全上下文。
