GRANT EXECUTE 权限必须授予存储过程对象本身，而非其操作的表或数据库；MySQL需用ON PROCEDURE、SQL Server需加OBJECT::前缀、Oracle跨schema须写全名。
GRANT EXECUTE 权限到底要授给谁？
执行存储过程报错 ERROR 1370 (42000): execute command denied to user 或 ORA-00904 / ORA-01031，核心原因不是“没权限”，而是权限没落在正确对象上。必须明确：EXECUTE 权限是授予「存储过程本身」的，不是授予它操作的表、视图或数据库。
常见误区是只给了表的 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 一般立即生效
真正卡住的地方往往不在授权语句本身，而在权限作用域的嵌套判断——是过程对象权限？是过程内语句涉及的对象权限？还是执行上下文的身份切换？每层都得单独验证，不能假设上一层通了下一层就自动通。
