根本原因是当前用户缺少TRIGGER权限，需显式授予GRANT TRIGGER ON db_name.* TO 'username'@'host';并确保DEFINER用户存在且具备触发器内SQL所需权限。
触发器创建失败提示 “TRIGGER command denied” 怎么办
根本原因是当前用户缺少 TRIGGER 权限，MySQL 5.7+ 默认不随 SELECT/INSERT 等权限自动授予。即使你有 CREATE 和 ALTER 权限，没有显式授权 TRIGGER 就无法创建或删除触发器。
检查方式很简单：
SHOW GRANTS FOR 'username'@'host';
如果输出里没有 GRANT TRIGGER ON ... 这一行，就是它了。
- 该权限必须针对具体数据库（不能用
*全局授予，除非你真要跨库操作触发器） -
TRIGGER是独立权限，ALL PRIVILEGES在 MySQL 8.0 之前也不包含它（8.0+ 才默认包含） - 执行
CREATE TRIGGER的用户，也必须对触发器中引用的表有对应操作权限（比如触发器里写了INSERT INTO log_table，就得有log_table的INSERT权限）
给用户添加 TRIGGER 权限的具体命令
授权语法和常见组合如下（注意替换 db_name、username、host）：
GRANT TRIGGER ON `db_name`.* TO 'username'@'host';
如果还需要配合其他操作，通常一并加上：
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX, TRIGGER ON `db_name`.* TO 'username'@'host';
授权后别忘了刷新：
FLUSH PRIVILEGES;
- MySQL 8.0+ 推荐用角色（role）管理，但直接授予权限仍是最常用方式
- 不要用
GRANT ALL ON *.*给普通应用用户——过度授权是安全漏洞源头 - 如果用户是通过代理或连接池登录，确认
host部分匹配（比如'user'@'10.0.1.%'不等于'user'@'localhost'）
触发器执行时报 “Access denied for trigger execution”
这说明触发器已存在，但执行时权限不足。常见于以下情况：
- 触发器定义者（
DEFINER）用户不存在，或该用户没有被触发器内 SQL 所需的权限 - 触发器里访问了其他数据库的表，但
DEFINER用户没被授予对应库的权限 - MySQL 启用了
sql_mode=NO_ENGINE_SUBSTITUTION以外的严格模式，且触发器中隐式依赖了未授权对象
查触发器定义：
SHOW CREATE TRIGGER trigger_name;
重点关注 DEFINER 字段，比如 DEFINER=`admin`@`%`。然后确认该用户是否存在、是否有对应权限：
SELECT User, Host FROM mysql.user WHERE User = 'admin';
SHOW GRANTS FOR 'admin'@'%';
临时解决（不推荐长期使用）：改用当前用户作为定义者（前提是当前用户权限足够）：
CREATE DEFINER=CURRENT_USER TRIGGER ...
为什么 root 能建触发器，普通用户却不行
因为 root 默认拥有 TRIGGER 权限，而新建普通用户时，MySQL 不会自动赋予它。哪怕你用 CREATE USER + GRANT ALL，在 MySQL 5.7 及更早版本中，ALL 也不含 TRIGGER —— 这是历史兼容性设计，容易被忽略。
验证方法：
SELECT * FROM information_schema.SCHEMA_PRIVILEGES WHERE PRIVILEGE_TYPE = 'TRIGGER' AND GRANTEE LIKE "'username%'";
如果查不到结果，就证实缺失。
最稳妥的做法：每次授权都显式加上 TRIGGER，尤其在自动化部署脚本里——它不像 SELECT 那样“看起来应该有”，而是静默失败的关键权限点。
