SQL Server触发器调试应写入专用日志表而非PRINT或RAISERROR；PostgreSQL需设置client_min_messages或用RAISE LOG；MySQL禁止修改同表，须用独立日志表并注意binlog_format。
SQL Server 触发器里怎么输出调试信息
SQL Server 的 AFTER 或 INSTEAD OF 触发器本身不支持 PRINT 在客户端实时显示（尤其在 SSMS 中执行 DML 时，PRINT 输出常被延迟或吞掉），更没法像应用层那样打日志文件。真要定位逻辑问题，得靠「可落地、可验证、不干扰事务」的日志落盘方式。
推荐用 INSERT INTO 写入专用日志表，而不是依赖 RAISERROR(..., 0, 1) WITH NOWAIT —— 后者在事务回滚时日志也消失，且容易被客户端忽略。
CREATE TABLE debug_log (id INT IDENTITY, event_time DATETIME2 DEFAULT GETDATE(), trigger_name SYSNAME, msg NVARCHAR(500), payload XML)- 触发器内用
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 为什么看不到输出
PostgreSQL 触发器里写 RAISE NOTICE 'debug: %', NEW.id; 是有效的，但输出是否可见，完全取决于客户端设置 —— psql 默认不显示 NOTICE 级别消息，而 pgAdmin 需手动打开「Messages」面板（不是 Query Tool 下方那个默认隐藏的 tab）。
- 在
psql中先执行SET client_min_messages = 'notice';才能看到 -
RAISE LOG会写入数据库服务端日志（路径由log_directory和log_filename控制），适合生产排查，但需 superuser 权限 - 不要在循环体或高频触发场景中滥用
RAISE NOTICE，它会显著增加 WAL 日志体积和锁竞争
MySQL 触发器无法写表？Can't update table 'x' in stored function/trigger
MySQL 严格禁止触发器内直接修改当前正在被 DML 操作的表（比如 INSERT 触发器里再 UPDATE 同一张表），这是引擎层硬限制，不是权限或语法问题。想留调试痕迹，只能绕开「写同表」这个雷区。
- 建一张独立日志表（如
trigger_debug_log），引擎必须是InnoDB（MyISAM在事务中不可靠） - 用
INSERT INTO trigger_debug_log SELECT ... FROM inserted形式记录，注意 MySQL 触发器没有inserted/deleted伪表，得用NEW/OLD - 如果连日志表都报错，检查是否启用了
binlog_format = STATEMENT—— 某些版本下它会导致触发器内 INSERT 失败，换成ROW更稳妥
所有数据库共通的调试陷阱：事务边界与日志可见性
最常被忽略的一点：触发器日志是否能“留下来”，取决于它是否和主 DML 共享同一事务上下文。一旦主语句回滚，你精心写的日志 INSERT 也会消失 —— 这让很多“以为记了日志”的人彻底抓瞎。
- SQL Server 可用
sp_getapplock+ 非事务日志表模拟自治事务效果（不完美但够用） - PostgreSQL 无法真正脱离事务，
RAISE LOG是唯一能逃逸的方式 - MySQL 8.0+ 支持
CREATE PROCEDURE声明CONTAINS SQL并调用外部程序写文件，但运维风险高，慎用
真要可靠，就接受一个事实：触发器调试日志，本质是“尽力而为”的辅助手段，不能替代单元测试或前置业务校验。把复杂逻辑移出触发器，才是长期不踩坑的起点。
