必须显式授予TRIGGER权限且仅对数据库级生效；仅SELECT/INSERT权限无法创建触发器，因其属对象定义操作，不包含在ALTER或ALL PRIVILEGES中。
必须显式授予 TRIGGER 权限，且仅对目标数据库生效；光有 ALTER 或 SELECT 权限不能创建或查看触发器。
为什么只给 GRANT SELECT, INSERT ON db1.t1 无法创建触发器
触发器不是普通查询或写入操作，MySQL 把它当作一种「数据库对象定义」来管控。TRIGGER 是独立权限项，不包含在 ALL PRIVILEGES（MySQL 8.0+）、ALTER、甚至 CREATE ROUTINE 里。用户即使能改表结构、能查能插，只要没被明确授予 TRIGGER，执行 CREATE TRIGGER 就会报错：
ERROR 1227 (42501): Access denied; you need (at least one of) the SUPER or TRIGGER privilege(s) for this operation
- 这个错误和
SUPER无关时，基本就是缺TRIGGER权限 - 检查方式：用管理员账号执行
SHOW GRANTS FOR 'u1'@'%';，确认输出里有TRIGGER ON `db1`.* - 注意作用域：不能写成
GRANT TRIGGER ON *.*给普通用户——MySQL 会拒绝（除非是root或带SUPER）
GRANT TRIGGER 的正确写法与常见误操作
语法必须严格匹配数据库级作用域，且需配合关联表的 DML 权限才能真正生效：
- 正确示例：
GRANT TRIGGER ON `db1`.* TO 'dev'@'%';（授予对整个db1库的触发器管理权） - 错误写法：
GRANT TRIGGER ON db1.t1 TO 'dev'@'%';→ MySQL 不支持表级TRIGGER授权，会报语法错误 - 隐式依赖：如果触发器体里要更新
t2表，用户还必须有UPDATE ON db1.t2，否则CREATE TRIGGER执行时直接失败（建表不报错，建触发器才报） - 别漏
FLUSH PRIVILEGES;？不用——GRANT命令本身会立即生效，只有直接修改mysql.user等系统表才需要手动刷新
从安全角度限制触发器权限的最小实践
生产环境不该让应用账号拥有 TRIGGER 权限。若必须授权，应遵循最小权限原则，并规避常见漏洞点：
- 禁止用
DEFINER = CURRENT_USER—— 这会让触发器以调用者身份执行，放大低权限账号的风险；应显式指定可信账号，如DEFINER = 'admin'@'localhost' - 避免在触发器中调用存储过程或函数，除非已单独授予
EXECUTE权限，否则运行时报错位置极难定位 - MySQL 8.0+ 推荐用角色统一管控：
CREATE ROLE 'trigger_dev'; GRANT TRIGGER ON `db1`.* TO 'trigger_dev'; GRANT INSERT, UPDATE ON `db1`.t1 TO 'trigger_dev'; GRANT 'trigger_dev' TO 'dev'@'%'; - 复制环境中特别注意：从库回放
CREATE TRIGGER语句时仍会校验TRIGGER权限，哪怕sql_log_bin = 0，所以mysqldump --triggers导入前得临时加权限
真正麻烦的不是授不授权，而是权限叠加后的隐式行为——比如有了 TRIGGER 又忘了撤 ALTER，用户就能删表再重建来绕过触发器逻辑。这类边界情况，靠单条 GRANT 命令根本覆盖不到。
