MySQL 8.0.16+才支持GRANT EXECUTE ON PROCEDURE，需满足版本≥8.0.16、用户已创建、先授USAGE权限、过程名带库名且DEFINER存在，否则CALL会静默失败或报ERROR 1370。
GRANT EXECUTE ON PROCEDURE 语法在 MySQL 8.0.16+ 才真正可用，但直接授给“特定过程”不是加个参数就完事——它依赖前置条件、版本限制和权限继承逻辑，跳过任何一环都会静默失败。
确认 MySQL 版本和基础用户存在
执行 SELECT VERSION();，确保返回值 ≥ 8.0.16。低于该版本（比如 8.0.15 或 5.7）执行 GRANT EXECUTE ON PROCEDURE db.sp_name 会报 ERROR 1064 (42000)，语法根本不被识别。
同时确认用户已创建（MySQL 8.0 要求先 CREATE USER，不能只靠 GRANT ... IDENTIFIED BY 一步到位）：
CREATE USER 'appuser'@'%' IDENTIFIED BY 'strongpass';- 若用户已存在，跳过这步；但别假设
SHOW GRANTS FOR 'appuser'@'%'有结果就代表账号有效——检查SELECT User, Host FROM mysql.user WHERE User = 'appuser';
必须先授 USAGE 权限，否则 EXECUTE ON PROCEDURE 失效
这是最容易漏掉的硬性前提：MySQL 8.0+ 要求用户对目标数据库有 USAGE 权限，GRANT EXECUTE ON PROCEDURE db.sp_name 才能生效。不报错，但后续 CALL 仍会失败。
执行以下两步缺一不可：
-
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 (42000): execute command denied 的真实原因
这个错误几乎从不因为没授 EXECUTE 权限，而是运行时权限校验失败。关键看过程定义：
- 执行
SHOW CREATE PROCEDURE mydb.calc_score;，检查DEFINER字段是否指向一个仍存在的高权限账号（如'admin'@'localhost'） - 如果
DEFINER账号已被删或权限不足，MySQL 会 fallback 到调用者权限（即appuser），此时哪怕EXECUTE授权成功，过程里一条SELECT otherdb.users就会因appuser缺otherdb的SELECT权限而报错 - 连接 host 不匹配：授权是
'appuser'@'10.0.1.%'，但应用连的是'appuser'@'localhost'—— MySQL 视为两个独立账号，权限不共享
想真正限制“只允许调用某几个过程”，得换思路
MySQL 原生不支持按过程名白名单控制。显式执行 REVOKE EXECUTE ON PROCEDURE mydb.calc_score FROM 'appuser'@'%' 完全无效，因为 EXECUTE 权限继承自数据库层级：只要用户有 mydb.* 的 EXECUTE，所有该库下过程都可调用。
可行路径只有两条：
- 把要开放的过程统一挪到专用库（如
api_routines），只对该库授GRANT EXECUTE ON `api_routines`.* TO 'appuser'@'%'，其他过程放别处 - 改过程安全模型：
ALTER PROCEDURE mydb.calc_score SQL SECURITY INVOKER;（需 DBA 操作），让内部 SQL 检查调用者权限——但这意味着你得同步给appuser授过程里所有表的对应权限（SELECT、INSERT等），管理成本陡增
最常被忽略的一点：EXECUTE 权限本身不解决过程内部的表访问问题。报错永远是笼统的 execute command denied，不会告诉你卡在哪张表——得靠 SHOW CREATE PROCEDURE 和 INFORMATION_SCHEMA.ROUTINES 交叉验证定义者与实际执行上下文。
