MS SQL Server AFTER INSERT触发器执行后无记录问题排查

首先咱们先理清核心矛盾：你配置了AFTER INSERT触发器，本意是把插入的行转成JSON推送到RabbitMQ，但现在插入操作完成后表中没有任何记录——这里要明确：AFTER INSERT触发器是在插入操作成功提交后才会触发的，所以没记录的大概率原因是插入操作本身被终止了，或者触发器里的逻辑导致整个事务回滚了。下面给你一步步拆解排查方案：

第一步：先排除触发器外的基础问题 #

先把触发器临时禁用（执行下面的语句），然后直接执行你的插入语句，看表中是否生成记录：

ALTER TABLE [dbo].[dbName] DISABLE TRIGGER [dbName_trigger]

• 如果还是没记录：那问题和触发器无关，要检查插入语句的语法、表的约束（比如主键冲突、非空字段未赋值、外键关联不存在）、执行账户的权限这些基础项。
• 如果插入正常：那问题肯定出在触发器或者关联的.NET存储过程上，继续往下查。

第二步：排查触发器本身的逻辑问题 #

1. 验证触发器是否触发+JSON生成是否正常 #

你可以临时给触发器加日志记录，把插入的JSON和执行状态存到一个日志表，方便排查：
首先创建日志表：

CREATE TABLE TriggerExecutionLog (
    LogId INT IDENTITY(1,1) PRIMARY KEY,
    InsertedJson NVARCHAR(MAX),
    ExecutionTime DATETIME DEFAULT GETDATE(),
    ErrorDetails NVARCHAR(MAX)
)

然后修改触发器：

ALTER TRIGGER [dbo].[dbName_trigger] ON [dbo].[dbName] AFTER INSERT AS 
BEGIN 
    SET NOCOUNT ON; 
    DECLARE @Inserted NVARCHAR(MAX) = (SELECT * FROM INSERTED FOR JSON AUTO)
    -- 先把插入的JSON写入日志
    INSERT INTO TriggerExecutionLog (InsertedJson) VALUES (@Inserted)
    
    BEGIN TRY
        IF NOT (@Inserted IS NULL) 
            EXECUTE dbo.StoredProcedure 'dbName', @Inserted 
    END TRY 
    BEGIN CATCH
        -- 捕获错误详情更新到日志
        UPDATE TriggerExecutionLog 
        SET ErrorDetails = CONCAT(
            '错误编号: ', ERROR_NUMBER(), 
            ' | 错误信息: ', ERROR_MESSAGE(),
            ' | 错误发生位置: ', ERROR_PROCEDURE(), ' 第', ERROR_LINE(), '行'
        )
        WHERE LogId = SCOPE_IDENTITY()
        
        -- 重点：这里默认如果事务处于不可提交状态，SQL会自动回滚
        -- 如果你希望即使存储过程失败，插入记录依然保留，可以注释掉下面的回滚语句
        -- IF XACT_STATE() <> 0
        --     ROLLBACK TRANSACTION;
    END CATCH 
END

修改后执行插入操作，然后查看TriggerExecutionLog：

• 如果没有日志记录：说明触发器根本没触发，检查触发器是否启用（执行SELECT name, is_disabled FROM sys.triggers WHERE name = 'dbName_trigger'，is_disabled应该为0）。
• 如果有日志但ErrorDetails不为空：直接看错误信息，就能定位到存储过程执行失败的原因。

2. 检查事务回滚的可能性 #

你的触发器里的CATCH块原本只返回错误编号，但SQL Server中如果TRY块内的代码抛出严重错误，会导致事务进入不可提交状态，即使你不手动回滚，最终整个插入事务也会被回滚，表中就不会有记录。

如果你的需求是：即使RabbitMQ推送失败，也要保留插入的记录，那可以在CATCH块中去掉自动回滚的逻辑（上面修改后的触发器已经注释了回滚语句），但要注意这种情况会出现“表中有记录，但队列没收到消息”的不一致，你需要后续做补偿处理（比如定时扫描表，把未推送的记录重新推送到队列）。

第三步：排查.NET存储过程的问题 #

因为存储过程是和RabbitMQ交互的，可能的问题点：

• 执行存储过程的SQL账户是否有足够的权限访问RabbitMQ服务器、写入指定队列？
• 存储过程中是否处理了RabbitMQ的连接异常？比如连接超时、队列不存在、权限不足这些情况，如果未处理，会抛出异常触发SQL的CATCH块，进而导致事务回滚。
• 存储过程接收的JSON参数是否格式正确？比如INSERTED中的某些字段转JSON后是否有特殊字符，导致存储过程解析失败？

总结排查流程 #

1. 禁用触发器验证基础插入是否正常。
2. 给触发器加日志，捕获执行细节和错误。
3. 根据日志中的错误信息，修复存储过程或触发器的逻辑。
4. 调整错误处理策略，平衡数据一致性和业务需求。

内容的提问来源于stack exchange，提问作者Imixal