如何配置MySQL授予存储过程执行权限以应用于具体应用场景？

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

MySQL的`EXECUTE`权限不是授予存储过程名，而是授予数据库或整体过程的执行能力。直接对用户执行以下命令会报错：

• 要授给整个库：用 GRANT EXECUTE ON database_name.* TO 'user'@'host'
• 要授给单个过程：用 GRANT EXECUTE ON PROCEDURE database_name.procedure_name TO 'user'@'host'（注意 PROCEDURE 关键字和点号分隔）
• 如果只给 SELECT 权限，哪怕过程里只查表，用户也无法调用——EXECUTE 是独立权限，不继承表级权限

调用时提示 “EXECUTE command denied” 怎么排查？

常见原因不是没给 EXECUTE，而是权限对象写错了。比如创建过程时用了 CREATE PROCEDURE mydb.p1，但授的是 GRANT EXECUTE ON mydb.* —— 这能用；可如果过程在 testdb，而你授的是 mydb.*，就完全无效。

• 确认过程所属库：SELECT db, name FROM mysql.proc WHERE name = 'procedure_name'
• 检查当前用户权限：SHOW GRANTS FOR 'user'@'host'，看是否含 EXECUTE 及对应库/过程范围
• 注意匿名用户或 'user'@'%' 和 'user'@'localhost' 是不同账户，权限不互通

DEFINER 和 INVOKER 对权限的影响

存储过程默认以 DEFINER 身份执行（即创建者权限），所以即使调用者只有 EXECUTE，过程内部也能做创建者能做的事。但若显式声明 SQL SECURITY INVOKER，则过程内所有操作都受调用者权限约束——这时候光有 EXECUTE 不够，还得确保调用者对过程里涉及的表也有对应权限（如 SELECT、INSERT）。

• 查看过程安全类型：SELECT db, name, definer, security_type FROM mysql.proc WHERE name = 'p1'
• 修改需重建：CREATE OR REPLACE PROCEDURE ... SQL SECURITY INVOKER（MySQL 8.0+ 支持，5.7 需先 DROP）
• DEFINER 方式更省权限配置，但存在提权风险；INVOKER 更安全，但权限管理更琐碎

MySQL 8.0 权限表结构变化带来的坑

MySQL 8.0 废弃了 mysql.proc 表，改用数据字典表，但 GRANT 语法没变。真正影响实操的是：8.0 默认启用 sql_mode=STRICT_TRANS_TABLES，如果过程里有未声明的变量或隐式类型转换，即使授权成功，调用时也可能因执行失败而看起来像权限问题。

• 检查过程是否有效：SELECT * FROM information_schema.ROUTINES WHERE ROUTINE_NAME = 'p1'
• 8.0 中 GRANT EXECUTE ON PROCEDURE 仍可用，但必须确保用户对 information_schema 有基本访问权（否则 SHOW PROCEDURE STATUS 报错）
• 升级后首次授权失败？先确认用户是否存在：SELECT user, host FROM mysql.user WHERE user = 'user'，8.0 的用户管理更严格

最常被忽略的点：权限变更后不会立即生效于已存在的连接。必须让目标用户断开重连，或管理员执行 FLUSH PRIVILEGES（仅当直接改表时才需要，正常 GRANT 会自动刷新）。