生产环境里触发器调试难，根本原因就一个：它不报错、不显形、不落日志——执行了你不知道，失败了你也看不见。
SQL Server 触发器 PRINT 为什么总“没输出”
在 SSMS 里执行 UPDATE 后看不到 PRINT 内容，不是代码写错了，是 SQL Server 的输出机制本身就不适合调试：
-
PRINT输出被缓冲，事务回滚时直接丢弃，而触发器出错常伴随回滚 - SSMS 默认不实时刷新消息面板，尤其批量操作时可能压根不显示
-
RAISERROR(..., 0, 1) WITH NOWAIT看似能强制刷出，但一旦事务回滚，这条消息也跟着消失
真正可落地的做法是写入日志表：INSERT INTO debug_log (trigger_name, msg, payload) VALUES (N'upd_order_status', N'before update', (SELECT * FROM inserted FOR XML AUTO))。注意这张表必须轻量（字段少、无外键、无索引），否则会拖慢主 DML 性能。
PostgreSQL 触发器 RAISE NOTICE 看不见？先查 client_min_messages
RAISE NOTICE 本身没问题，问题出在客户端默认屏蔽了 NOTICE 级别消息：
- psql 中需先执行
SET client_min_messages = 'notice';才能看到 - pgAdmin 要手动打开「Messages」面板（不是 Query Tool 下方那个默认隐藏的 tab）
- 生产排查建议用
RAISE LOG，它写入数据库服务端日志（路径由log_directory和log_filename控制），但需要 superuser 权限
高频触发场景中慎用 RAISE NOTICE，它会显著增加 WAL 日志体积和锁竞争，甚至引发性能抖动。
MySQL 触发器里 INSERT 日志表报错 Can't update table 'x'
这不是权限或语法问题，是 MySQL 引擎层硬限制：触发器内禁止修改当前正在被 DML 操作的表。想留痕迹，只能绕开：
- 建一张独立日志表（如
trigger_debug_log），引擎必须是InnoDB（MyISAM在事务中不可靠） - 用
INSERT INTO trigger_debug_log SELECT NEW.id, NEW.status, NOW() FROM DUAL形式记录，不能用inserted/deleted（MySQL 没这伪表） - 如果连日志表都插不进，检查
binlog_format是否为STATEMENT——某些版本下会导致触发器内INSERT失败，换成ROW更稳妥
所有数据库共通的一点是：日志表必须与业务表物理分离，且上线前确认触发器 DEFINER 用户对日志表有真实 INSERT 权限——否则日志写不进去，你还以为触发器根本没跑。
最易被忽略的其实是时间精度和清理策略：日志表若用 DATETIME 而非 DATETIME(3)，高并发下多条日志可能时间戳完全一样；若不设定期清理任务，几天后这张表就会成为性能瓶颈本身。
