mysql 8.0.16+才支持grant execute on procedure语法，但须先授usage权限且不可用通配符；trigger权限仅库级、不可表级；execute与trigger严格分离，不可互换；“execute denied”多因definer上下文或表级权限缺失。
GRANT EXECUTE ON PROCEDURE 在 MySQL 8.0.16+ 才真正可用
MySQL 5.7 及更早版本压根不识别 GRANT EXECUTE ON PROCEDURE db.sp_name TO 'u'@'%'，执行直接报 ERROR 1064。8.0.16+ 虽支持该语法，但有两个硬性前提：
- 必须先授予数据库级
USAGE权限：GRANT USAGE ON `db`.* TO 'u'@'%'；跳过这步，后续授权会静默失败 - 不能用通配符代替过程名：
GRANT EXECUTE ON PROCEDURE db.*是非法的；若想授整个库所有 routine，得用GRANT EXECUTE ON db.*
触发器权限是库级的，且无法收缩到表
TRIGGER 权限只能按库授予，例如 GRANT TRIGGER ON `mydb`.* TO 'dev'@'%'，MySQL 不允许 GRANT TRIGGER ON `mydb`.`orders` 这种写法。这意味着：
- 哪怕你只想让某用户管理
orders表的触发器，也必须开放整个mydb库的触发器创建/删除权 - 用户获得
TRIGGER后，能在该库任意表（包括mysql系统表）上建触发器，存在敏感表暴露风险 - MySQL 5.7 及以前要求
SUPER权限，升级到 8.0+ 后才可用TRIGGER替代，这是最常被忽略的版本差异
CALL 存储过程报 “EXECUTE command denied” 的真实原因
这个错误几乎从不表示没给 EXECUTE 权限，而是暴露了更底层的问题：
- 过程默认是
SQL SECURITY DEFINER，内部 SQL 以定义者身份执行——但定义者（如'root'@'localhost'）虽有权限，调用者却可能缺对应表的SELECT或UPDATE权限 - 用
SHOW CREATE PROCEDURE db.sp_name查DEFINER，再确认调用者是否拥有过程内所有 DML 涉及表的显式权限，例如过程里有INSERT INTO logs，就得单独GRANT INSERT ON mydb.logs TO 'user'@'%' - 若想让过程校验调用者权限，必须重建为
SQL SECURITY INVOKER；但修改DEFINER需要SET USER权限，普通用户无法自行操作
EXECUTE 和 TRIGGER 权限完全不可互换
这是权限模型里最容易混淆的一点：二者严格按对象类型隔离，混用必失败。
-
EXECUTE只用于调用已存在的存储过程或函数，对触发器无效；GRANT EXECUTE ON PROCEDURE给再多，也无法让用户建触发器 -
TRIGGER只控制能否在某个库下创建/删除触发器，跟运行无关；给用户TRIGGER权限，不代表他能调用任何存储过程 -
CREATE ROUTINE和EXECUTE完全解耦：能创建 ≠ 能执行；即使你是过程创建者，没显式授予EXECUTE，自己也调不了——因为默认不自动继承
实际中真正难控制的不是“能不能执行”，而是“执行时以谁的身份检查权限”。SQL SECURITY DEFINER 下，定义者权限再高，也救不了调用者缺失的表级权限；而 INVOKER 模式又要求调用者本身具备完整链路权限。这两者之间的权衡，比单纯授个 EXECUTE 或 TRIGGER 更容易被忽略。
