mysql支持对单个存储过程和函数细粒度授权，但必须严格使用grant execute on procedure db.sp_name和grant execute on function db.func_name语法，缺一不可；mysql 5.7不支持该语法，8.0.16+才稳定支持，且需先授予usage权限。
GRANT EXECUTE ON PROCEDURE 和 FUNCTION 语法必须写全
MySQL 支持对单个存储过程和函数做细粒度授权，但前提是语法不能省略关键部分。常见错误是漏掉 PROCEDURE 或 FUNCTION 关键字，或省略数据库前缀。
正确写法只有两种：
GRANT EXECUTE ON PROCEDURE mydb.sp_name TO 'user'@'localhost';GRANT EXECUTE ON FUNCTION mydb.func_name TO 'user'@'localhost';
以下全部无效：
-
GRANT EXECUTE ON mydb.sp_name TO ...→ 缺PROCEDURE，报语法错误 -
GRANT EXECUTE ON PROCEDURE sp_name TO ...→ 缺数据库名，MySQL 解析失败 -
GRANT EXECUTE ON FUNCTION mydb.* TO ...→*不适用于函数/过程粒度，只用于mydb.*这种库级通配
必须先有 USAGE 权限，否则 PROCEDURE/FUNCTION 授权会静默失败
MySQL 8.0.16+ 要求用户对目标数据库至少拥有 USAGE 权限，否则 GRANT EXECUTE ON PROCEDURE 语句虽不报错，但实际不生效。
实操步骤必须按顺序执行：
GRANT USAGE ON `mydb`.* TO 'user'@'localhost';GRANT EXECUTE ON PROCEDURE mydb.sp_report TO 'user'@'localhost';GRANT EXECUTE ON FUNCTION mydb.calc_total TO 'user'@'localhost';
验证方式不是只看 SHOW GRANTS，而是用该用户连接后实测：CALL mydb.sp_report(); 和 SELECT mydb.calc_total(100);。若报 ERROR 1370 (42000)，大概率是漏了第一步。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
SQL SECURITY DEFINER 是权限绕过的根源
即使你精确授予了某个函数的 EXECUTE 权限，如果该函数定义为 SQL SECURITY DEFINER（默认值），且其 DEFINER 是高权限账号（如 'root'@'%'），那么函数内部的 SELECT、UPDATE 等操作将完全绕过调用者权限检查。
真正起作用的是这个设置：
- 创建时指定：
CREATE DEFINER='appuser'@'%' SQL SECURITY INVOKER FUNCTION mydb.safe_calc(...) ... - 修改已有函数：
ALTER FUNCTION mydb.calc_total SQL SECURITY INVOKER;（需有ALTER ROUTINE权限）
不改 SQL SECURITY，所有细粒度授权都只是表面控制——调用能过，但函数体内读敏感表仍可能成功。
REVOKE 单个过程/函数权限在旧版本中根本无效
MySQL 5.7 及更早版本根本不识别 REVOKE EXECUTE ON PROCEDURE 语法；8.0+ 虽支持，但存在继承逻辑：只要用户有 EXECUTE ON `mydb`.*，再执行 REVOKE EXECUTE ON PROCEDURE mydb.sp_x FROM ... 也不会阻止调用。
所以「限制只能用 A、不能用 B」的可靠做法只有两个：
- 把 A 和 B 拆到不同数据库，比如
sp_a()放proc_a库，只授EXECUTE ON `proc_a`.* - 不依赖函数本身，改用视图 + 基础表权限组合，把计算逻辑下推到应用层或封装成带行级过滤的查询
函数和过程本质是服务端计算入口，一旦开放 EXECUTE，就等于交出一部分执行上下文控制权——这点比表权限难收口得多。
