MySQL 8.0中EXECUTE权限必须显式授予且角色需激活才生效：即使用户拥有ALL PRIVILEGES，调用存储过程仍报ERROR 1370；须单独GRANT EXECUTE ON PROCEDURE db.proc_name TO 'u'@'%'，并为角色执行SET DEFAULT ROLE激活，否则权限无效。
EXECUTE 权限必须显式授予，否则调用存储过程直接报错 ERROR 1370 (42000)——这是最直观的体现。MySQL 8.0 不再把执行权当作“附带权限”，而是和 SELECT、INSERT 并列的一级权限。
为什么 GRANT 后仍报 “execute command denied”？
常见错误现象：用户对数据库有 ALL PRIVILEGES，也能查表、删数据，但一调用 CALL proc_name() 就失败。
-
EXECUTE在 8.0 中是独立权限，不随SELECT或ALL自动获得 - 即使你用
GRANT ALL ON db.* TO 'u'@'%'，也不会包含EXECUTE - 正确做法是单独执行：
GRANT EXECUTE ON PROCEDURE db.proc_name TO 'u'@'%' - 如果过程在系统库（如
mysql），普通账号默认无权执行，需显式授权且注意mysql库权限受额外限制
CREATE PROCEDURE 和 ALTER PROCEDURE 权限不再互通
5.7 中建完过程后常能直接改，8.0 强制拆分操作边界：
-
CREATE PROCEDURE只允许新建，不赋予修改或删除权 -
ALTER PROCEDURE是独立权限，迁移脚本若含ALTER PROCEDURE但没授此权，会报ERROR 1044 (42000) -
DROP PROCEDURE同样需要DROP ROUTINE权限，不能靠CREATE ROUTINE覆盖 - 想让某用户能给他人授权执行某个过程，必须加
WITH GRANT OPTION，且对象要写全：GRANT EXECUTE ON PROCEDURE db.proc_name TO 'u'@'%' WITH GRANT OPTION
角色（ROLE）启用后，EXECUTE 授权容易漏掉关键步骤
8.0 支持角色，但角色不会自动生效：
- 创建角色并授权后：
CREATE ROLE 'proc_runner'; GRANT EXECUTE ON PROCEDURE db.proc_name TO 'proc_runner'; - 把角色赋给用户：
GRANT 'proc_runner' TO 'app_user'@'%'; - 必须执行：
SET DEFAULT ROLE 'proc_runner' TO 'app_user'@'%';，否则用户登录后仍无执行权 - 自动化部署脚本里常漏掉
SET DEFAULT ROLE，导致权限配置“看起来成功了，实际无效”
真正麻烦的不是语法变多，而是旧系统里那些“默认能跑”的过程，在 8.0 下必须逐个确认 EXECUTE 是否显式授予，且角色激活、插件兼容、host 精确匹配这些点交织在一起，单点修复往往掩盖不了全部问题。
