必须显式授予 TRIGGER 权限，且仅对数据库级生效；光有 SELECT/INSERT 权限无法创建触发器。
为什么 GRANT TRIGGER ON db.table 不起作用？
MySQL 不支持表级 TRIGGER 授权。写成 GRANT TRIGGER ON mydb.orders TO 'u1'@'%' 会直接报错 ERROR 1064。正确语法只能是数据库粒度：GRANT TRIGGER ON mydb.* TO 'u1'@'%'。这是 MySQL 的硬性限制，不是版本差异——从 5.7 到 8.0 均如此。很多用户误以为“能操作某张表”就自然能管它的触发器，结果卡在语法错误上。
CREATE TRIGGER 失败的常见权限组合漏项
即使 GRANT TRIGGER ON mydb.* 成功执行，CREATE TRIGGER 仍可能失败，原因通常是触发器体内部操作涉及了其他表或对象，而这些没授对应权限：
- 触发器里写了
INSERT INTO logs→ 必须额外GRANT INSERT ON mydb.logs TO 'u1'@'%' - 触发器里查了
departments表 → 补GRANT SELECT ON mydb.departments TO 'u1'@'%' - 触发器调用了函数
gen_id()→ 还要GRANT EXECUTE ON FUNCTION mydb.gen_id TO 'u1'@'%' - 触发器跨库写入
sys.audit_log→ 得单独GRANT INSERT ON sys.audit_log TO 'u1'@'%'
检查方式：用管理员账号执行 SHOW CREATE TRIGGER trigger_name，逐行扫出所有被引用的对象和操作类型。
谁可以执行 GRANT TRIGGER？
只有持有 GRANT OPTION 的账号才能授 TRIGGER 权限。普通用户即使被给了 CREATE ROUTINE 或 EXECUTE，也不能转授 TRIGGER。如果执行 GRANT 时提示 Access denied; you need the GRANT OPTION privilege，说明当前登录账号没资格发授权命令。不要尝试绕过——比如直接更新 mysql.tables_priv，风险高且重启后可能失效。
MyWebSQL 界面里勾选 Trigger 就完事了？
MyWebSQL 的「Trigger」复选框实际执行的是全局 GRANT TRIGGER ON *.*，这在生产环境极不安全。它等价于 GRANT TRIGGER ON *.* TO 'u1'@'%'，意味着该用户能在所有库上建触发器。除非是 DBA 专用账号，否则应避免。更稳妥的做法是：退出 MyWebSQL，用命令行执行精确到库的授权，例如 GRANT TRIGGER ON app_db.* TO 'u1'@'%'，并配合角色（CREATE ROLE trigger_dev）做权限复用。
真正容易被忽略的点是：权限生效不依赖 FLUSH PRIVILEGES（GRANT 命令本身立即生效），但客户端连接若复用旧会话，可能缓存旧权限。验证前务必重新登录或用新连接测试 CREATE TRIGGER，别只看 SHOW GRANTS 输出里有没有 TRIGGER 关键字。
