EXECUTE权限单独控制是因为存储过程可能执行写操作、跨库查询或动态SQL，需按最小权限原则仅授予调用动作本身所需权限，而非继承SELECT等其他权限。
为什么 EXECUTE 权限单独控制，而不是随 SELECT 一起给？
MySQL 把存储过程执行权和定义权完全拆开：有 CREATE ROUTINE 不代表能运行，有 SELECT 也不代表能调用 CALL proc_name()。这是因为存储过程可能包含写操作、跨库查询、甚至动态 SQL，权限必须按实际行为收敛——只给「执行」这个动作本身所需的最小权限。
常见错误现象：ERROR 1370 (42000): execute command denied to user 'u'@'%' for routine 'db.proc_name'，哪怕用户对整个库都有 SELECT 权限，照样报错。
- 权限粒度是「每个存储过程」或「整个数据库」，不能按 schema 粗粒度继承
-
GRANT EXECUTE ON PROCEDURE db.proc_name TO 'u'@'%'是最安全的写法，不暴露定义逻辑 - 如果用
GRANT EXECUTE ON db.* TO 'u'@'%'，用户能执行该库下所有现有及未来新建的存储过程（含别人创建的）
如何确认当前用户缺的是不是 EXECUTE 权限？
别急着赋权，先验证是不是权限问题。直接查 mysql.procs_priv 表太绕，更可靠的方式是模拟用户视角查元数据：
SHOW GRANTS FOR 'u'@'%';
看输出里有没有 EXECUTE 相关条目；没有就基本确定是权限缺失。另外注意两点：
- 用户连接时用的 host 必须和
GRANT语句里的完全一致（'u'@'localhost'≠'u'@'%'） - 执行
FLUSH PRIVILEGES不是必须的，但如果你刚改了mysql库的表（比如手动 INSERT），就得刷 - 如果用户是通过角色（role）间接获得权限，要检查角色是否被激活：
SELECT CURRENT_ROLE();
GRANT EXECUTE 后还是报错？检查这三处
赋权命令跑成功不代表生效。以下情况会导致权限看似给了实则无效：
- 存储过程定义者（
DEFINER）权限不足：比如DEFINER='root'@'localhost'，但 root 在当前上下文没对应权限，调用时会以 definer 身份校验——这时得给 root 补权限，或改用SQL SECURITY INVOKER - 过程里用了
SELECT其他库的表，但用户没被授予那些库的权限——EXECUTE只管“调用动作”，不管过程内部干了什么 - MySQL 8.0+ 默认开启
check_proxy_users或启用了 PAM 插件，导致权限链被拦截；可临时用SELECT USER(), CURRENT_USER();看实际认证用户是否和预期一致
生产环境慎用的两种 EXECUTE 赋权方式
有些做法短期能跑通，但埋了运维雷：
- 给
root或高权限账号设为DEFINER，却不显式授权——看似省事，但一旦 root 密码轮换或账号锁定，所有依赖它的过程全挂 - 用
GRANT ALL ON db.* TO 'u'@'%'替代精确的EXECUTE授权——这等于把DROP PROCEDURE、ALTER ROUTINE全开了，违背最小权限原则 - 在初始化脚本里漏掉
DELIMITER，导致GRANT语句被当成存储过程体的一部分解析失败（错误信息常是ERROR 1064）
真正难处理的其实是权限链路嵌套：一个过程调另一个过程，后者又访问视图，视图底层还连着外部 FEDERATED 表……这种时候单看 EXECUTE 没用，得一层层顺下去查实际执行路径上的每道权限卡点。
