如何通过GRANT EXECUTE授权有效解决存储过程执行权限不足问题？

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

执行存储过程时出现错误：

常见误区是只给了表的 SELECT 权限，却忘了对存储过程对象单独授权。尤其在 MySQL 和 SQL Server 中，GRANT EXECUTE ON PROCEDURE db_name.proc_name TO 'user'@'host' 是不可跳过的一步。

• MySQL：必须指定 PROCEDURE 关键字，不能写成 GRANT EXECUTE ON db_name.*（那是授整个库的存储过程权限）
• SQL Server：语法为 GRANT EXECUTE ON OBJECT::dbo.proc_name TO [user]，漏掉 OBJECT:: 前缀会报错
• Oracle：用 GRANT EXECUTE ON proc_name TO username，注意不加 schema 前缀时默认是当前用户 schema；跨 schema 调用必须写全 GRANT EXECUTE ON other_schema.proc_name TO username

为什么加了 GRANT EXECUTE 还报错？检查 SQL SECURITY 或 AUTHID

即使已执行 GRANT EXECUTE，调用仍失败，大概率是存储过程定义时用了 SQL SECURITY DEFINER（MySQL）或默认的 DEFINER 模式（Oracle/SQL Server），导致权限校验绕过了调用者，转而检查创建者（DEFINER）是否还存在、是否有底层对象权限。

例如 MySQL 中创建时写了 CREATE PROCEDURE p1() SQL SECURITY DEFINER，而该 DEFINER 用户已被删，或其对某张表的 SELECT 权限被回收，则调用者哪怕有 EXECUTE 权限也会失败。

• MySQL：用 SHOW CREATE PROCEDURE proc_name 查看当前 SQL SECURITY 设置；如需切换为调用者权限，重建时加 SQL SECURITY INVOKER
• Oracle：检查是否含 AUTHID DEFINER（默认），若想让调用者权限生效，显式声明 AUTHID CURRENT_USER
• SQL Server：默认走所有权链，但若过程里用了 EXECUTE AS，则实际检查的是 EXECUTE AS 指定用户的权限，不是调用者也不是创建者

跨 schema / 跨用户访问表时，EXECUTE 权限不够用

GRANT EXECUTE 只解决“能不能调这个过程”，不解决“过程内部能不能读写其他用户的表”。比如 Oracle 存储过程中有 INSERT INTO other_user.t1 ...，或 MySQL 里 SELECT * FROM other_db.table1，这时必须额外给调用者（或 DEFINER）授予对应表的 SELECT、INSERT 等权限。

特别注意 Oracle 的角色权限陷阱：通过角色（如 DBA）获得的 CREATE ANY TABLE 在存储过程中默认无效，必须显式 GRANT CREATE ANY TABLE TO username —— 角色权限在定义者权限模式下不继承。

• MySQL：若过程访问 other_db.t1，需确保 DEFINER 或 INVOKER 有 other_db.t1 的相应权限
• SQL Server：启用所有权链（同 schema）可省略表级授权；否则必须 GRANT SELECT ON other_schema.t1 TO [user]
• Oracle：跨用户表操作，必须由目标用户执行 GRANT SELECT ON t1 TO caller_user，不能靠角色间接赋权

GRANT EXECUTE 后仍被拒绝？确认用户 host 和大小写

MySQL 最容易踩的坑是用户账号的 host 不匹配。例如你执行了 GRANT EXECUTE ON PROCEDURE mydb.p1 TO 'app'@'localhost'，但应用连接时用的是 'app'@'127.0.0.1' 或 'app'@'%'，权限就完全不生效。

另外，MySQL 默认用户名大小写敏感（取决于系统变量 lower_case_table_names），而存储过程名在大多数版本中是大小写敏感的。如果过程名为 GetUser，却写成 GRANT EXECUTE ON PROCEDURE mydb.getuser，授权会静默失败。

• 查真实用户：用 SELECT User, Host FROM mysql.user 确认账号全貌
• 查过程名：用 SELECT ROUTINE_NAME FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'mydb'
• 授权后刷新：MySQL 需 FLUSH PRIVILEGES（仅修改 mysql 表后必要）；SQL Server / Oracle 一般立即生效

真正卡住的地方往往不在授权语句本身，而在权限作用域的嵌套判断——是过程对象权限？是过程内语句涉及的对象权限？还是执行上下文的身份切换？每层都得单独验证，不能假设上一层通了下一层就自动通。