MySQL 8.0.16+才支持GRANT EXECUTE ON PROCEDURE db.proc_name语法，必须显式指定库名和过程名、加反引号、先授予USAGE权限，5.7及更早版本不支持该语法，直接报ERROR 1064。
GRANT EXECUTE ON PROCEDURE 语法必须带库名和过程名
直接写 GRANT EXECUTE ON myproc TO 'u'@'%' 会报错 ERROR 1064 (42000)；MySQL 不接受省略数据库名的写法。哪怕过程就在当前默认库，也必须显式写出 `db_name`.`proc_name`。
正确写法示例：GRANT EXECUTE ON PROCEDURE `app_db`.`get_user_summary` TO 'api_user'@'10.20.%';
- 反引号
`必须保留——当库名或过程名含下划线、数字开头、或为 MySQL 关键字（如order）时，不加会解析失败 - 不能用通配符代替过程名，
GRANT EXECUTE ON PROCEDURE app_db.*是非法语法 - MySQL 8.0.16+ 才真正支持该语法；5.7 及更早版本执行即报错，需改用
GRANT EXECUTE ON app_db.*全库授权
必须先授 USAGE 权限，否则 PROCEDURE 授权静默失效
在 MySQL 8.0.16+ 中，GRANT EXECUTE ON PROCEDURE db.proc_name 要生效，用户必须已拥有对应数据库的 USAGE 权限。跳过这步，命令看似成功，但实际权限不会写入系统表，CALL 仍报 EXECUTE command denied。
实操顺序必须是：
GRANT USAGE ON `app_db`.* TO 'api_user'@'10.20.%';GRANT EXECUTE ON PROCEDURE `app_db`.`get_user_summary` TO 'api_user'@'10.20.%';
注意：USAGE 是空权限占位符，不赋予任何能力，仅作为后续细粒度授权的前提；它不会出现在 SHOW GRANTS 输出中，需查 mysql.db 表确认。
EXECUTE 权限 ≠ 查看源码权限，但默认 DEFINER 模式会暴露表结构
只给 EXECUTE，用户无法执行 SHOW CREATE PROCEDURE——那需要 ALTER ROUTINE 权限，而该权限同时允许修改和删除过程，生产环境不应授予。
但问题在于：如果过程是默认的 SQL SECURITY DEFINER（即未显式声明 INVOKER），且 DEFINER 是高权限账号（如 'dba'@'%'），那么调用者即使没 SELECT 权限，也能拿到结果，数据本身就会泄露字段名、类型、业务逻辑边界。
- 过程定义里明文写着
SELECT id, name, email FROM users，一旦用户有ALTER ROUTINE或能查INFORMATION_SCHEMA.ROUTINES，表结构全暴露 - 动态 SQL 报错（如
Table 'app_db.nonexistent' doesn't exist）也会反推表名 - 真正隔离实现细节，必须重建过程并加
SQL SECURITY INVOKER，让每条内部 SQL 都校验调用者权限
REVOKE 单个过程权限无效，这是设计行为不是 bug
执行 REVOKE EXECUTE ON PROCEDURE app_db.get_user_summary FROM 'api_user'@'10.20.%' 不会起作用——只要该用户仍有 app_db.* 级别的 EXECUTE 权限，就能调用库内所有过程。
MySQL 的 routine 权限继承自数据库层级，8.0 前甚至没有独立的 routine 权限位。所以：
- 想精确控制单个过程，只能靠
GRANT EXECUTE ON PROCEDURE+SQL SECURITY INVOKER组合 - 若用户已有
app_db.*的EXECUTE，再单独REVOKE某个过程，权限系统直接忽略 - 验证是否生效，别信
SHOW GRANTS，直接CALL app_db.get_user_summary()测试，或查mysql.procs_priv表
最易被忽略的点是：SQL SECURITY INVOKER 不是授权动作，而是过程定义的一部分；不重建或 ALTER PROCEDURE，光授 EXECUTE 权限毫无意义。
