必须drop再create，因mysql不支持alter trigger；执行后需用show create trigger比对代码是否完全一致，并确认definer存在、权限充足、上下文正确。
SHOW CREATE TRIGGER 输出和你改的代码不一致
MySQL 不支持 ALTER TRIGGER，所谓“修改”只是在客户端编辑了 SQL，但没真正替换掉已加载的触发器。你执行 CREATE OR REPLACE TRIGGER 或直接粘贴新定义，MySQL 会报错（如果同名已存在）或静默忽略（某些客户端行为），根本不会更新内存中的触发器逻辑。
实操建议：
- 必须先执行
DROP TRIGGER IF EXISTS trigger_name;，再执行CREATE TRIGGER ... - 执行完立刻运行
SHOW CREATE TRIGGER trigger_name;，逐字比对输出和你的源码是否完全一致（包括空格、换行、大小写） - 确认当前数据库上下文：跨库操作前必须
USE db_name;，否则SHOW TRIGGERS查不到，SHOW CREATE TRIGGER也会报错 - 注意权限：
DROP TRIGGER需要TRIGGER权限，且对目标表有ALTER权限；否则语句看似成功，实际没生效
触发器被禁用或 DEFINER 用户失效
SQL Server 有 DISABLE TRIGGER，MySQL 虽无显式禁用语法，但 DEFINER 用户不存在或权限缺失，效果等同于“禁用”——INSERT 成功，触发器逻辑却一丁点没跑，还不报错。
实操建议：
- 查定义：
SHOW CREATE TRIGGER trigger_name;看DEFINER=`xxx`@`yyy`是谁 - 查用户是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'xxx' AND Host = 'yyy'; - 查权限：
SHOW GRANTS FOR 'xxx'@'yyy';，确保含触发器内所有操作所需的权限（如INSERT ON audit_db.log_table） - 别用
DEFINER = CURRENT_USER()，它取的是连接认证用户，不是你本地登录账号；生产环境应显式指定可信用户，如DEFINER = 'trigger_worker'@'%'
触发器内部报错被静默吞掉
MySQL 触发器里出错（比如字段不存在、违反外键、UPDATE 同表报 ERROR 1442），默认不抛给客户端。你看到 “Query OK”，其实原 DML 和触发器一起回滚了，但没人告诉你。
实操建议：
- 立即执行
SHOW WARNINGS;—— 很可能看到Can't update table 'orders' in stored function/trigger - 查 MySQL 错误日志：
SELECT @@log_error;，然后去对应路径搜ERROR+ 表名 + 触发器名 - 避免在触发器里写
UPDATE same_table SET ...；BEFORE 触发器可改NEW字段影响本行入库值，AFTER 触发器只能做副作用操作（如写日志表） - MySQL 8.0+ 中，若
UPDATE没实际变更任何字段（如SET status = status），整个触发器会被跳过，不执行、不报错、不警告
从库上触发器根本不执行
主从复制只同步 binlog 事件，不传播触发器逻辑。主库 INSERT 触发 AFTERT INSERT 往 log_table 插一行，这个插入动作不会进 binlog；从库重放原始 INSERT，但不会再次触发自己的触发器——这不是 bug，是设计如此。
实操建议：
-
SHOW VARIABLES LIKE '%slave_run_triggers%';—— 这个变量根本不存在，任何试图设置它的操作都会报错，网上教程全是误导 - 如果硬要在从库也跑逻辑，必须同时满足：
binlog_format = STATEMENT（不推荐，易主从不一致）、从库手动创建同名触发器、且read_only = OFF - 更可靠的做法是把逻辑提到应用层双写，或用
Canal/Maxwell监听 binlog 做下游投递 - 别信 SSMS 或 Navicat 的“刷新”图标——它不 reload 触发器状态，必须手动查
information_schema.TRIGGERS或sys.triggers
DROP 再 CREATE，以及以为“语句没报错=逻辑跑通”。
