mysql 8.0.16+ 支持 grant execute on procedure，但需先授 usage 权限；权限继承自数据库级，revoke 单个过程权限无效；关键在 sql security 设置为 invoker 以启用调用者权限检查。
如何给用户授予特定存储过程的执行权限
MySQL 不支持直接对单个存储过程授 EXECUTE 权限，必须先确保用户有数据库级的 EXECUTE 权限，再配合细粒度的对象级控制（如视图封装、权限隔离）来间接限制。这是最容易误解的起点——很多人以为 GRANT EXECUTE ON PROCEDURE db.sp_name TO 'u'@'%' 能生效，其实 MySQL 5.7 及以前版本根本不认这种语法；8.0+ 虽然支持，但仅限于 routine 级授权，且要求用户已有对应数据库的 USAGE 权限。
实操建议：
- 确认 MySQL 版本：
SELECT VERSION();，8.0.16+ 才真正稳定支持GRANT EXECUTE ON PROCEDURE - 先授数据库基础权限：
GRANT USAGE ON `db`.* TO 'u'@'%';（不能跳过，否则 procedure 授权会失败） - 再授具体过程权限：
GRANT EXECUTE ON PROCEDURE db.sp_analyze_logs TO 'u'@'%'; - 刷新权限：
FLUSH PRIVILEGES;（尤其在直接改表或用旧方式授权后）
为什么直接 revoke 所有 routine 权限仍可能执行成功
因为 MySQL 的 EXECUTE 权限继承自数据库层级：只要用户有 db.* 的 EXECUTE，哪怕你显式 REVOKE EXECUTE ON PROCEDURE db.sp_x FROM 'u'@'%'，该用户依然能调用所有该库下的存储过程。这不是 bug，是设计逻辑——routine 权限在 8.0 前根本不存在独立权限位，全靠数据库级开关控制。
常见错误现象：
-
REVOKE EXECUTE ON PROCEDURE db.sp_x FROM 'u'@'%';执行无报错，但CALL db.sp_x()仍成功 - 用户没有
SELECT权限，却能通过存储过程读取敏感表（因过程内以 definer 权限执行）
关键点在于：存储过程默认以 DEFINER 身份执行，不是调用者身份。所以即使你限制了调用者权限，只要 DEFINER 是高权限账号（比如 'root'@'localhost'），过程内部 SQL 就能绕过调用者权限检查。
如何让存储过程按调用者权限运行
必须显式声明 SQL SECURITY INVOKER，否则默认是 DEFINER。这是控制权限边界的真正开关，不改这个，其他授权都是隔靴搔痒。
实操建议：
- 创建时指定：
CREATE DEFINER='admin'@'%' SQL SECURITY INVOKER PROCEDURE db.sp_count_users() ... - 修改现有过程：
ALTER PROCEDURE db.sp_count_users SQL SECURITY INVOKER;（注意：需有ALTER ROUTINE权限） - 验证当前设置：
SELECT ROUTINE_NAME, SQL_SECURITY FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA='db' AND ROUTINE_NAME='sp_count_users';
性能影响很小，但兼容性要注意：若过程内用了调用者无权访问的表或函数，INVOKER 模式下会直接报 ERROR 1142 (42000): SELECT command denied to user，而 DEFINER 模式下可能静默返回空结果或错误数据。
用视图 + 存储过程组合实现最小权限访问
当无法控制 DEFINER 或需要更精细的数据行级过滤时，最稳妥的做法是把核心逻辑拆到视图，再让存储过程只做轻量封装，并严格限制调用者对视图的权限。
使用场景：
- 运维人员只能查自己部门的日志，但日志表本身要全局可写
- 报表用户只能调用汇总过程，但不能看到原始明细表结构
示例流程：
- 建安全视图：
CREATE VIEW db.v_user_summary AS SELECT dept, COUNT(*) c FROM users GROUP BY dept; - 授视图权限：
GRANT SELECT ON db.v_user_summary TO 'reporter'@'%'; - 过程只查视图：
CREATE PROCEDURE db.sp_get_dept_count(IN d VARCHAR(20)) BEGIN SELECT c FROM v_user_summary WHERE dept = d; END - 不授任何基表权限，只授过程执行权
这种模式下，即使过程被恶意重定义，攻击面也局限在视图暴露的字段和逻辑里。真正的难点不在语法，而在厘清“谁该看到什么数据”——权限设计一旦脱离业务语义，再严格的 SQL 控制也会失效。
