TRIGGER 权限被拒绝的典型报错
执行
CREATE TRIGGER时遇到
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or TRIGGER privilege(s) for this operation，说明当前用户缺少
TRIGGER权限——MySQL 5.7+ 默认不自动授予该权限，即使有
CREATE或
ALTER权限也不够。
给用户显式授予 TRIGGER 权限
必须由高权限账号（如
root）执行授权语句，且注意作用域：
GRANT TRIGGER ON `database_name`.* TO 'username'@'host';—— 仅对指定库生效，最常用
GRANT TRIGGER ON *.* TO 'username'@'host';—— 全局权限，生产环境慎用 授予权限后必须执行
FLUSH PRIVILEGES;（仅当直接操作
mysql系统表后才强制需要；使用
GRANT语句通常自动刷新） 若用户已存在但无任何权限，需先
CREATE USER，再
GRANT
检查当前用户实际拥有的权限
不要依赖记忆或旧文档，用命令实时验证：
登录 MySQL 后执行SHOW GRANTS FOR CURRENT_USER;—— 查看当前会话用户权限（注意不是
USER()） 若看到输出中没有
TRIGGER，说明确实缺失 权限可能来自不同 host 匹配（如
'user'@'localhost'和
'user'@'%'是两个独立账号），确认连接时用的是哪个
SELECT User, Host FROM mysql.user WHERE User = 'username';可查账号注册情况
SUPER 权限不是替代方案
虽然错误提示里提到
SUPER，但不应为普通应用账号开这个权限：
SUPER允许修改全局变量、杀线程、绕过 binlog 写入等高危操作，违反最小权限原则 MySQL 5.7.6+ 已将
TRIGGER拆为独立权限，不再依赖
SUPER如果误授了
SUPER，应立即回收：
REVOKE SUPER ON *.* FROM 'username'@'host';云数据库（如阿里云 RDS、腾讯云 CDB）通常禁用
SUPER，此时必须走
TRIGGER授权路径
触发器权限问题常卡在「以为已有 CREATE 就够了」或「没注意 host 匹配细节」，真正要动的就一行
GRANT TRIGGER，但得确保对象、范围和生效状态都对得上。
