撤销TRIGGER权限后仍能创建触发器，是因为MySQL中TRIGGER权限需与ALTER（或SUPER）权限配合生效；仅撤TRIGGER而保留ALTER，触发器创建不受限。
撤销用户 TRIGGER 权限后为什么还能创建触发器？
MySQL 的 TRIGGER 权限控制的是「在指定数据库下创建/删除触发器」的能力，但它**不独立生效**——用户必须同时拥有对应表的 ALTER 权限（或 SUPER 权限），才能成功创建触发器。所以只 revoke TRIGGER，而没动 ALTER，触发器照建不误。
- 常见错误现象：
REVOKE TRIGGER ON `db1`.* FROM 'u1'@'%';执行成功，但u1仍能对db1.t1创建触发器 - 根本原因：该用户仍有
ALTER权限（比如当初用GRANT ALL PRIVILEGES ON db1.*授过权） - 验证方式：
SHOW GRANTS FOR 'u1'@'%';查看是否含ALTER
如何真正禁止用户创建触发器？
必须组合撤销两个权限：表级 ALTER + 数据库级 TRIGGER。注意权限作用域要匹配——对某张表禁用触发器，就得撤该表的 ALTER；若想全局禁止，就撤整个库的 ALTER。
-
REVOKE ALTER ON `db1`.`t1` FROM 'u1'@'%';—— 撤销对单表的结构修改权（含创建触发器） -
REVOKE TRIGGER ON `db1`.* FROM 'u1'@'%';—— 补上触发器专项权限撤销 - 如果用户有
SUPER权限，上述操作无效；需先REVOKE SUPER ON *.* FROM 'u1'@'%'; - 执行后记得
FLUSH PRIVILEGES;（仅当直接改了 mysql 系统表时才强制需要，常规REVOKE会自动生效）
用 GRANT 代替 REVOKE 更安全？
直接 REVOKE 可能误删其他必要权限（比如不小心把 SELECT 也撤了）。更稳妥的做法是：显式用 GRANT 重置最小可用权限集，把 TRIGGER 和 ALTER 明确排除在外。
- 例如只给查询和插入：
GRANT SELECT, INSERT ON `db1`.`t1` TO 'u1'@'%'; - 这样既避免残留权限，又不会影响已有业务逻辑
- 注意：
GRANT不会自动清除未列出的旧权限，必须先REVOKE ALL PRIVILEGES再重新GRANT，否则旧权限还在 - MySQL 8.0+ 支持角色（
CREATE ROLE），可预定义「只读角色」「DML角色」，比逐个用户管理更可控
触发器权限在复制环境中的特殊表现
主从复制中，从库默认以 sql_log_bin=0 执行触发器相关语句，但权限检查仍会发生。如果从库用户缺少 TRIGGER 权限，即使不写 binlog，CREATE TRIGGER 语句在从库回放时也会报错：ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER or TRIGGER privilege(s) for this operation。
- 典型场景：用
mysqldump --triggers导出再导入到权限受限的从库 - 解决方法：导入前临时授权
GRANT TRIGGER ON `db1`.* TO 'repl_user'@'%';，导入完立即收回 - MySQL 5.7 及以前版本，
TRIGGER权限还影响SHOW CREATE TABLE是否显示触发器定义（8.0+ 已修复）
权限边界比表面看到的窄，TRIGGER 是个依赖型权限，它自己站不住——得盯着 ALTER、SUPER、甚至复制用户的上下文。
