GRANT EXECUTE权限授予用户对数据库或具体存储过程的执行能力，须用GRANT EXECUTE ON database.*或GRANT EXECUTE ON PROCEDURE db.procedure_name语法；EXECUTE是独立权限，不继承表级权限，且受DEFINER/INVOKER安全上下文影响。
GRANT EXECUTE 权限到底给谁？
MySQL 的 EXECUTE 权限不是授予「存储过程名」，而是授予「数据库」或「具体过程」的执行能力。直接对用户执行 GRANT EXECUTE ON procedure_name TO 'user'@'host' 会报错：ERROR 1064 (42000) —— 因为语法不合法。
- 要授给整个库：用
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）。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查看过程安全类型：
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 会自动刷新）。
