触发器根本没被调用，首要排查是否启用：mysql查information_schema.triggers中status是否为enabled，sql server查sys.triggers中is_disabled是否为0；truncate操作天然不触发dml触发器，因属ddl、不生成伪表；update无实际变更时（如set x=x）在mysql 8.0+中也可能跳过触发器。
触发器根本没被调用，先查是否启用
触发器“存在但不执行”最常见原因就是它被禁用了。MySQL 和 SQL Server 都不会报错、不提示、不写日志，它就安静地挂在那里。你执行 INSERT，语句成功，@@rowcount 正常，但触发器逻辑压根没跑。
- MySQL：运行
SELECT TRIGGER_NAME, STATUS FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name';，确认STATUS是ENABLED；若为DISABLED，执行ALTER TRIGGER your_trigger_name ENABLE;（注意：MySQL 5.7 不支持该语法，只能DROP TRIGGER后重建） - SQL Server：运行
SELECT name, is_disabled FROM sys.triggers WHERE name = 'your_trigger_name';，若is_disabled = 1，执行ENABLE TRIGGER your_trigger_name ON your_table; - 别信 SHOW TRIGGERS 输出——它只查当前库，跨库必须先
USE db_name
TRUNCATE 或 UPDATE 无变更时触发器天然不触发
TRUNCATE 是 DDL 操作，不是 DML，它不逐行处理、不生成 inserted/deleted 伪表，因此任何 INSERT/UPDATE/DELETE 类型的触发器都完全不会运行。这不是配置问题，是设计如此。
- 想清空表又走触发器？必须改用
DELETE FROM table_name（带或不带WHERE） - MySQL 8.0+ 中，如果
UPDATE语句实际未修改任何字段（例如SET name = name），默认跳过触发器——检查@@sql_mode是否含STRICT_TRANS_TABLES，否则这种“无效更新”会被静默忽略 - SSIS、应用代码里用了
TRUNCATE + BULK INSERT组合？整个链路里触发器全程静默，得从源头改
触发器内报错却被吞掉，怎么看到真实错误？
触发器失败通常不抛给客户端，而是让主语句失败或直接静默。你以为没执行，其实是执行了但崩在半路，输出被吞了。
- 执行完疑似触发失败的
INSERT/UPDATE后，立刻运行SHOW WARNINGS;，常能捕获触发器内部的真实错误，比如Unknown column 'xxx' in 'field list' - 打开 MySQL 错误日志：
SET GLOBAL log_warnings = 2;，并确认log_error指向可读路径（如/var/log/mysql/error.log），关键词搜ERROR+ 表名 + 触发器名 - SQL Server 中，
PRINT或RAISERROR输出需客户端开启SET NOCOUNT OFF才能看见；否则你以为没执行，其实是输出被屏蔽了
触发器写了但逻辑没生效，这些细节容易被忽略
真正难定位的从来不是语法错误，而是“执行了但没效果”。比如你在触发器里往日志表插记录，结果查不到——可能因为日志表和主表同名/同库引发锁冲突，或者触发器根本没走到那行代码。
- 跨库操作必须写全路径：
INSERT INTO audit_log是错的，得写INSERT INTO sys_log.audit_log，且执行用户要有对应权限（INSERT ON sys_log.audit_log） - 触发器里不能有
SELECT返回结果集（会报ERROR 1415），也不能有COMMIT/ROLLBACK（报ERROR 1422） - MySQL 的
ERROR 1442是硬限制：不能在触发器中修改“正在被操作的同一张表”，哪怕通过存储函数间接调用也不行；临时表中转或移到应用层是仅有的可行解
DEFINER 用户没权限写日志表，又恰巧 sql_mode 不严格，结果整段逻辑静默跳过。排查时得一层层剥，不能只盯代码。
