要看到触发器真实错误，MySQL立即执行SHOW WARNINGS；SQL Server需开启SET NOCOUNT OFF并用TRY...CATCH写入日志表；PostgreSQL应配置log_statement='all'或log_error_verbosity='verbose'；所有平台均需避免CATCH中仅RETURN而不THROW，并确认触发器已成功编译启用。
触发器报错却没提示，怎么看到真实错误？
触发器执行失败时，数据库通常不会把错误原样抛给客户端，而是静默吞掉或让主语句失败却不说明原因。你以为操作成功了，其实触发器中途崩了，数据已不一致。
MySQL 下立刻执行 SHOW WARNINGS;，多数内部错误（比如 Unknown column 'xxx' in 'field list'、Subquery returns more than 1 row）都会出现在这里。别等第二天查日志，就在此刻查。
SQL Server 中需确保客户端开启了 SET NOCOUNT OFF，否则 PRINT 或 RAISERROR 输出全被屏蔽；更可靠的是用 TRY...CATCH 捕获后写入日志表，例如：
INSERT INTO trigger_error_log (trigger_name, error_number, error_message, log_time) VALUES (OBJECT_NAME(@@PROCID), ERROR_NUMBER(), ERROR_MESSAGE(), GETDATE());
- MySQL 错误日志要打开：运行
SET GLOBAL log_warnings = 2;，并确认log_error配置指向可读路径 - PostgreSQL 需开启
log_statement = 'all'或log_error_verbosity = 'verbose'，再复现操作 - 所有数据库中，避免在
CATCH块里只写RETURN而不THROW，否则等于主动吃掉异常
为什么触发器里加了 TRY CATCH 还是没反应？
常见误区是以为加了 TRY...CATCH 就万事大吉，但 SQL Server 的 CATCH 只捕获严重级别 11–19 的错误；像引用不存在的列（级别 16）、死锁（级别 13）能被捕获，但某些编译期错误（如表名拼错）根本进不了 TRY 块——它在触发器加载时就失败了。
真正起效的前提是：触发器本身能成功编译并挂载到表上。先用 SELECT name, is_disabled, object_id FROM sys.triggers WHERE name = 'your_trigger' 确认状态为启用且无编译错误。
- MySQL 没有
TRY...CATCH，得靠DECLARE EXIT HANDLER FOR SQLEXCEPTION，且必须放在触发器最开头 - PostgreSQL 使用
EXCEPTION块，但注意：它不能捕获QUERY CANCELED（如超时）这类系统级中断 - 所有平台中，事务回滚由外层控制，
CATCH里不能执行COMMIT或ROLLBACK（除非自治事务），否则直接报错
INSERTED/DELETED 为空导致触发器静默退出，怎么防？
UPDATE 语句实际没改任何值（如 SET status = status）、或 TRUNCATE 表、或批量操作中部分行被 WHERE 过滤掉——这些场景下 INSERTED 或 DELETED 可能为空集。若触发器逻辑直接从伪表取值（如 SELECT @id = id FROM inserted），变量会为 NULL，后续判断失效，整个逻辑跳过。
必须在开头加防御性检查：
IF NOT EXISTS (SELECT 1 FROM inserted) AND NOT EXISTS (SELECT 1 FROM deleted) RETURN;
- MySQL 触发器没有伪表概念，但
NEW/OLD在 DELETE 中NEW为空、INSERT 中OLD为空，引用前要用IF NEW.id IS NOT NULL判断 - SQL Server 中，对多行操作不能依赖标量变量，必须用集合操作（如
UPDATE t SET modified_at = GETDATE() FROM target t INNER JOIN inserted i ON t.id = i.id） - PostgreSQL 的
NEW/OLD是行变量，单行触发器默认可用，但声明为FOR EACH STATEMENT时它们为 NULL，务必匹配触发粒度
禁用触发器后操作仍异常，问题出在哪？
DISABLE TRIGGER 不是立即生效的开关——它只影响新启动的事务。如果当前已有事务正在执行，触发器照常运行；你禁用后马上跑一条 INSERT，它仍会走旧逻辑。这种“延迟生效”极易误导排查方向。
真正要验证是否生效，得新开一个连接或显式 COMMIT / ROLLBACK 当前事务后再试。
- MySQL 中
ALTER TABLE ... DISABLE TRIGGER同样延迟生效，且SHOW TRIGGERS不显示启用状态，必须查information_schema.TRIGGERS.STATUS - 禁用后别忘了清理残留副作用：比如审计触发器禁用期间产生的脏数据，或未同步的汇总表
- 临时禁用只是应急手段，不是根治方案；恢复前务必补跑缺失逻辑（如重放变更日志），否则一致性缺口会越拉越大
