如何精确设置MySQL用户只能调用特定存储过程的权限？

本文共计914个文字，预计阅读时间需要4分钟。

仅能执行特定存储过程，需精确到库名.过程名，不能使用通配符，也不能依赖数据库级别的权限携带。

为什么 GRANT EXECUTE ON mydb.* 对存储过程无效

MySQL 的 EXECUTE 权限不支持数据库级通配授权。写成 GRANT EXECUTE ON mydb.* TO 'u'@'%' 会被 MySQL 忽略——它只认具体过程名。常见错误是误以为和 SELECT 权限一样能批量授权，结果 CALL 仍报 ERROR 1370 (42000): execute command denied。

必须显式指定：

• GRANT EXECUTE ON PROCEDURE mydb.proc_a TO 'u'@'%'
• GRANT EXECUTE ON PROCEDURE mydb.proc_b TO 'u'@'%'

如果过程在 mysql 系统库下，普通用户默认无权调用，也不建议把业务过程放那里。

SQL SECURITY INVOKER 是限制执行边界的真正开关

光有 EXECUTE 权限还不够：过程内部的 SQL（比如 SELECT FROM orders）是否能跑通，取决于 SQL SECURITY 设置。默认是 DEFINER，意味着过程以创建者身份查表——这等于变相提权。

要真正限制用户“只能做过程允许的事”，必须声明：

CREATE PROCEDURE mydb.get_user_summary() SQL SECURITY INVOKER BEGIN SELECT id, name FROM users WHERE status = 'active'; END

这样，即使过程存在，只要调用者没 SELECT 权限，执行时就会直接报错，不会绕过。

不声明时 MySQL 5.7+ 默认为 DEFINER，但若定义者账号被删或权限回收，过程会突然失效。

用户能调用，但看不到源码？这是权限分离的正常表现

很多 DBA 以为“能 CALL 就该能 SHOW CREATE PROCEDURE”，其实不是。EXECUTE 和查看定义是两套权限：

• EXECUTE → 允许调用
• ALTER ROUTINE → 允许查看、修改、删除定义（注意：这个权限实际包含删除能力，慎授）

所以，只给 EXECUTE 的用户执行 SHOW CREATE PROCEDURE mydb.proc_a 会报 ERROR 1370 (42000): alter routine command denied。这不是 bug，是设计如此。

如果真需要开放查看权限，且不想给修改/删除能力，MySQL 8.0+ 可考虑通过视图 INFORMATION_SCHEMA.ROUTINES 配合行级过滤间接实现，但原生不支持“只读定义”粒度。

动态授权类过程必须用 SQL SECURITY DEFINER + 高权限 DEFINER

如果过程里要执行 GRANT 或 REVOKE（比如封装权限分配逻辑），不能直接写，必须用 PREPARE + EXECUTE 动态 SQL，并确保：

• 过程显式声明 SQL SECURITY DEFINER
• DEFINER 是真实存在的高权限账户（如 'dba'@'%'），且拥有 GRANT OPTION
• 不能设为 CURRENT_USER，也不能省略 DEFINER 字段

否则会报 ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) 或更隐蔽的静默失败（比如目标用户不存在时 GRANT 不报错也不生效）。

最易被忽略的一点：EXECUTE 是独立权限，不随 SELECT/INSERT 自动附带；而过程内 SQL 的执行边界，只取决于 SQL SECURITY 设置，跟谁写的无关。