SQL Server触发器中PRINT无效，应使用RAISERROR(...,10,1)WITH NOWAIT或插入调试表；需配置SSMS显示消息，避免影响性能与事务。
SQL Server 触发器里不能用 PRINT
在 AFTER 或 INSTEAD OF 触发器中直接写 PRINT，你根本看不到输出——它不会出现在 SSMS 的“消息”选项卡，也不会被应用程序捕获。因为触发器运行在事务上下文中，PRINT 输出被缓冲且不主动刷新，更关键的是：多数客户端（比如 .NET 的 SqlCommand）默认忽略服务器端的 PRINT 消息。
- 真正能被 SSMS “看到”并显示在“消息”窗口的，只有
RAISERROR(..., 10, 1) WITH NOWAIT -
RAISERROR级别必须 ≤ 10，否则会中断事务（而调试信息不该导致回滚） -
WITH NOWAIT是关键，它绕过缓冲，强制立刻发送到客户端 - 不要用
THROW替代——它总是中断执行，不适合纯调试
如何在 INSERT/UPDATE/DELETE 触发器中安全打日志
想确认某条记录是否进了触发器、字段值是否如预期，最轻量的做法是往一张专用调试表里插一行，而不是依赖客户端显示。因为生产环境可能关掉消息输出，或根本没人在看 SSMS。
- 建一张最小结构的调试表：
CREATE TABLE dbo.TriggerDebug (id INT IDENTITY, ts DATETIME2 DEFAULT GETDATE(), msg NVARCHAR(500)) - 在触发器里用
INSERT INTO dbo.TriggerDebug (msg) VALUES (CONCAT('Inserted: ', ISNULL(CAST(INSERTED.id AS VARCHAR), 'null'))) - 避免在调试语句里查大表或加锁；只记录必要字段，别拼接整个
INSERTED行 - 上线前记得删掉或注释掉这些
INSERT，否则影响性能和日志体积
SQL Server Management Studio 中必须打开“结果”和“消息”双窗口
即使用了 RAISERROR(..., 10, 1) WITH NOWAIT，如果 SSMS 设置不对，你还是看不见。这不是代码问题，是客户端配置。
- 执行前手动点开两个标签页：“结果”（显示查询返回集）和“消息”（显示
RAISERROR输出） - 检查菜单栏：查询 → 查询选项 → 执行 → 高级 → 勾选“将 SET NOCOUNT 设为 False”（否则某些情况下消息被抑制）
- 注意：如果你用的是“仅 SQLCMD 模式”，
PRINT会显示，但RAISERROR WITH NOWAIT反而可能失效——别混用模式
触发器调试信息对事务和性能的真实影响
你以为只是“打个印”，但它可能让并发变慢、阻塞变多，尤其在高频更新的表上。
- 每次
RAISERROR WITH NOWAIT都要走网络协议栈，哪怕客户端是本地 SSMS；高频率下容易成为瓶颈 - 写调试表虽不阻塞主逻辑，但如果没建索引、没定期清理，
TriggerDebug表本身会膨胀，影响INSERT性能 - 千万别在触发器里调用
xp_cmdshell或外部脚本打日志——权限、安全、稳定性全崩 - 最隐蔽的坑：调试语句里引用了
DELETED或INSERTED，但触发器类型不匹配（比如INSERT触发器里读DELETED），直接报错中断
调试信息不是临时补丁，它本身就是业务逻辑的一部分——只要留在触发器里，就得按生产代码的标准去评估它的锁、IO 和网络行为。
