mysql 8.0起execute权限必须显式授予，不再随select或all privileges隐式获得；未授权时调用存储过程直接报error 1370，且受definer/invoker模式及角色默认激活状态影响。
EXECUTE 权限不是“附带赠送”的，必须显式授予——这是 MySQL 8.0 起最核心的变化。普通 SQL 查询只要用户有 SELECT 权限就能跑，而存储过程哪怕只查一张表，没授 EXECUTE 就直接报 ERROR 1370 (42000)。
为什么 GRANT EXECUTE ON PROCEDURE 是强制步骤？
MySQL 8.0 彻底剥离了“隐式执行权”：
- ALL PRIVILEGES 不再包含 EXECUTE
- CREATE ROUTINE 或 ALTER ROUTINE 和执行无关
- 即使过程只读、只查一张已授权的表，没 EXECUTE 仍拒绝调用
常见错误是迁移脚本里漏掉这句，结果应用一 CALL 就崩，报错却提示“command denied for routine”，而不是“no SELECT privilege”——容易误判根源。
DEFINER 和 INVOKER 模式让权限检查变复杂
过程定义时的 SQL SECURITY 设置会改变权限校验主体：
- DEFINER（默认）：以定义者身份检查内部语句权限。若 DEFINER='root'@'localhost'，但调用者账号对过程里某张表没 SELECT，照样报 EXECUTE command denied，而非更具体的表权限错误
- INVOKER：以调用者身份检查，要求调用者自己拥有过程内所有表的对应权限，灵活性高但权限收敛难
查定义用：SHOW CREATE PROCEDURE db_name.proc_name；改定义需 DBA 执行 ALTER DEFINER，普通用户无权操作。
角色（ROLE）不自动激活，SET DEFAULT ROLE 容易被跳过
用角色批量管理 EXECUTE 权限时，三步缺一不可：
- CREATE ROLE 'proc_executor'
- GRANT EXECUTE ON PROCEDURE db.proc_name TO 'proc_executor'
- GRANT 'proc_executor' TO 'app_user'@'%'，且必须紧接着执行 SET DEFAULT ROLE 'proc_executor' TO 'app_user'@'%'
漏掉最后一句，用户登录后角色不生效，CALL 仍失败。自动化部署脚本里常忽略这个显式激活动作。
EXECUTE 权限粒度很细，通配符不能跨库滥用
EXECUTE 必须按 db_name.object_name 精确指定，不支持模糊匹配：
- ✅ GRANT EXECUTE ON PROCEDURE mydb.sync_data TO 'u'@'h'
- ✅ GRANT EXECUTE ON mydb.* TO 'u'@'h'（授权该库下所有过程和函数）
- ❌ GRANT EXECUTE ON PROCEDURE *.* TO ...（全局通配极危险，8.0 已不推荐）
- ❌ GRANT EXECUTE ON PROCEDURE mydb.% TO ...（% 在过程名位置无效，语法错误）
真正麻烦的不是语法写不对，而是旧系统里靠“库级 ALL”混过去的逻辑，在 8.0 下必须逐个核对过程名并补授权。
实际落地时最常卡住的点，是把 EXECUTE 当成“能调用就行”，却没同步确认 DEFINER 是否具备过程内所有操作所需的底层权限，或者忘了给角色用户设默认激活。这两处一漏，错误现象完全一样，但排查路径完全不同。
