grant execute on procedure 和 grant trigger 权限必须分开授予，execute 仅用于调用存储过程或函数，trigger 仅控制创建/删除触发器；二者不可互换，且均需按对象类型和范围（库级或具体对象）精确授权，不可混用或通配。
GRANT EXECUTE ON PROCEDURE 和 GRANT TRIGGER 权限必须分开授
存储过程和触发器的执行权限不是一回事，不能混用 EXECUTE 去管触发器，也不能用 TRIGGER 去跑存储过程。MySQL 严格按对象类型区分权限边界：
-
EXECUTE只用于调用已存在的存储过程或函数：GRANT EXECUTE ON PROCEDURE mydb.calc_tax TO 'reporter'@'localhost'; -
TRIGGER仅控制能否在某个库下创建/删除触发器：GRANT TRIGGER ON `mydb`.* TO 'devuser'@'%'; - 给用户
ALL PRIVILEGES看似省事，但会意外开放DROP TABLE、ALTER ROUTINE等高危操作，违背最小权限原则
调用存储过程时报 “EXECUTE command denied” 不一定是没给 EXECUTE 权限
这个错误常被误判。真实原因更可能是过程内部 SQL 所需的表级权限缺失，或 DEFINER 上下文不匹配：
- 用
SHOW CREATE PROCEDURE mydb.my_proc;查看定义者（DEFINER），如果它是'root'@'localhost'，而当前用户没有该过程里UPDATE orders的权限，MySQL 就报EXECUTE command denied，而非更具体的UPDATE command denied - 若想让过程以调用者身份检查权限，应重建为
SQL SECURITY INVOKER；但修改DEFINER需要SET USER权限，普通用户无法自行操作 - 确保调用者拥有过程内所有 DML 涉及表的显式权限，例如过程里有
INSERT INTO logs，就得单独GRANT INSERT ON mydb.logs TO 'user'@'%';
MySQL 5.7 和 8.0+ 在触发器权限上行为完全不同
版本差异直接决定你能不能用普通账号建触发器，不注意这点，CREATE TRIGGER 必然失败：
- MySQL 5.7 及以前：必须有
SUPER权限才能执行CREATE TRIGGER，哪怕只对单个库操作 —— 这是运维最常踩的坑，报错ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) - MySQL 8.0+：
SUPER已废弃，改用库级TRIGGER权限，可精确到GRANT TRIGGER ON `mydb`.* TO 'dev'@'%'; -
TRIGGER权限无法收缩到表级，只要授了，用户就能在该库任意表（包括mysql系统表）上建触发器，需警惕敏感表暴露风险
CREATE ROUTINE 和 EXECUTE 权限完全解耦
能创建 ≠ 能执行，这是 MySQL 权限模型里最容易混淆的一点：
-
CREATE ROUTINE只控制能否定义/修改/删除存储过程或函数，跟运行无关；没它，CREATE PROCEDURE直接报错 -
EXECUTE是纯运行权，即使你是过程创建者，没显式授予EXECUTE，自己也调不了 —— 因为默认不自动继承 - 常见错误是只授
CREATE ROUTINE就以为万事大吉，结果CALL my_proc()仍报权限拒绝；必须补上GRANT EXECUTE ON PROCEDURE mydb.my_proc TO 'user'@'%';
实际配权限时，别只盯着“让功能跑起来”，得同步确认调用者是否真有过程体里每条 SQL 的落地权限——尤其是跨库查询、写日志表、更新状态字段这些隐性依赖。
