TRIGGER权限需显式授予且为数据库级，MySQL 5.7+不包含于ALL PRIVILEGES，8.0+废除SUPER隐式覆盖；创建/修改触发器还需DML、DROP、EXECUTE等配套权限，缺一不可。
TRIGGER权限必须显式授予，不能靠ALL PRIVILEGES自动获得
MySQL 5.7+ 中，TRIGGER 是独立的权限类型，即使你给用户授了 ALL PRIVILEGES ON database_name.*，也不会包含 TRIGGER。不单独授予就会报错：ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or TRIGGER privilege(s) for this operation。
注意两点：
-
TRIGGER权限是数据库级的，语法只能是GRANT TRIGGER ON database_name.* TO 'user'@'host'；写成ON database_name.table_name会直接报ERROR 1064 - MySQL 8.0+ 已移除
SUPER权限的隐式覆盖能力，别指望用它绕过TRIGGER授权
创建触发器还需配套的DML权限
光有 TRIGGER 不够。触发器体里执行什么操作，就得对应什么权限：
-
BEFORE INSERT触发器里写了SET NEW.status = 'pending'→ 只要TRIGGER就够 - 但若里面还有
INSERT INTO audit_log ...→ 必须额外GRANT INSERT ON database_name.audit_log TO 'user'@'host' - 如果触发器里
SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id→ 还得加GRANT SELECT ON database_name.orders TO 'user'@'host'
漏掉任意一项，触发器创建时可能成功，但运行时报错（比如 ERROR 1142: SELECT command denied）。
修改触发器本质是 DROP + CREATE，需要双重权限
MySQL 不支持 ALTER TRIGGER。所谓“修改”，实际分两步：先 DROP TRIGGER，再 CREATE TRIGGER。这就要求用户同时拥有：
-
TRIGGER权限（用于重建） -
DROP权限（用于删除原触发器）——注意不是表级DROP，而是对触发器所在库的DROP权限：GRANT DROP ON database_name.* TO 'user'@'host'
常见坑：DROP TRIGGER 不校验 DEFINER，但没 DROP 权限会直接卡在第一步，报 ERROR 1142 (42000): DROP command denied to user。
函数调用、跨库操作等隐式权限容易被忽略
触发器里一旦涉及外部对象，权限链就变长了：
- 调用了自定义函数
gen_uuid()→ 必须GRANT EXECUTE ON FUNCTION database_name.gen_uuid TO 'user'@'host' - 写入另一库的表：
INSERT INTO sys.log_table ...→ 需要GRANT INSERT ON sys.log_table TO 'user'@'host'，仅给当前库权限无效 - 触发器里用了
SELECT ... FOR UPDATE→ 还得确认用户有该表的UPDATE权限（即使没真正改数据）
最稳妥的做法：执行 SHOW CREATE TRIGGER trigger_name，逐行检查所有对象名和操作类型，再一一补全权限。权限改完别忘了 FLUSH PRIVILEGES 或让连接重连生效。
