SQL Server触发器无法异步调用存储过程，因其与DML共享事务上下文；必须用Service Broker实现真正异步：触发器仅发XML消息，激活过程在独立会话中处理。
不能直接让触发器“异步调用”存储过程——SQL Server 的 AFTER 触发器本身运行在主事务上下文中，任何阻塞、耗时或失败的存储过程调用都会拖慢甚至卡死 INSERT/UPDATE/DELETE 操作。真要异步，必须绕过触发器直接执行逻辑，改用 Service Broker 机制中转。
为什么不能在触发器里直接 EXEC 存储过程
触发器不是后台线程，它和原始 DML 共享同一个事务锁和执行上下文：
-
EXEC dbo.usp_AuditLog若含WAITFOR、远程调用、大事务或未捕获异常，会直接让主表操作超时或回滚 - 即使加了
TRY...CATCH，只要存储过程里有写日志、发 HTTP、查其他库等操作，仍可能因连接池耗尽、网络抖动、目标库慢而拖垮主流程 - SQL Server 不允许在触发器中启动新会话或新开事务来“脱钩”，
sp_start_job等方案延迟高、不可靠、难追踪
必须用 Service Broker 实现真正异步中转
Service Broker 是 SQL Server 原生的队列通信机制，它把“触发动作”和“后续处理”物理隔离：
- 触发器只做两件事：建对话（
BEGIN DIALOG CONVERSATION）+ 发 XML 消息（SEND），全程毫秒级，不碰业务表锁 - 消息进队列后，由 SQL Server 自动唤起激活存储过程（
ACTIVATION PROCEDURE），该过程运行在独立会话、独立事务中，失败不影响主流程 - 关键配置项必须显式设对：
ENCRYPTION = OFF（单库场景无需证书）、VALIDATION = WELL_FORMED_XML（消息体必须合法 XML）、MAX_QUEUE_READERS = 2（并发读取数别设太高） - 示例片段（触发器内）：
BEGIN TRY DECLARE @h UNIQUEIDENTIFIER; BEGIN DIALOG CONVERSATION @h FROM SERVICE [//Audit/Initiator] TO SERVICE '//Audit/Target' ON CONTRACT [//Audit/Contract] WITH ENCRYPTION = OFF; <p>SEND ON CONVERSATION @h MESSAGE TYPE [//Audit/MsgType] (SELECT INSERTED.id, INSERTED.name, GETDATE() AS ts FOR XML AUTO, ROOT('event'), TYPE); END TRY BEGIN CATCH IF ERROR_NUMBER() IN (9619, 9627) RETURN; -- 对话失败就静默退出，不阻塞 END CATCH
接收端激活存储过程必须防堆积、防残留
光发消息不够，接收端写错一句，消息就在 sys.transmission_queue 里越积越多，最后撑爆 tempdb：
- 激活过程开头必须加
IF @@TRANCOUNT > 0 ROLLBACK—— 否则上游触发器回滚后，激活过程还在处理已失效的消息 -
RECEIVE必须配WAITFOR，避免空轮询；收到消息后必须END CONVERSATION，漏掉这句会导致sys.conversation_endpoints中对话状态长期为CONVERSING - 不要手动
WHILE (1=1)循环收消息，交给 SQL Server 的 ACTIVATION 机制自动调度更稳 - 创建队列时务必指定：
CREATE QUEUE AuditQueue WITH ACTIVATION ( STATUS = ON, PROCEDURE_NAME = dbo.usp_ProcessAuditMessage, MAX_QUEUE_READERS = 2, EXECUTE AS OWNER );
最容易被忽略的是 broker 状态检查：执行完 ALTER DATABASE YourDB SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE 后，必须切回目标库再查 sys.databases.is_broker_enabled，值为 1 才算真正生效；备份还原后这个标志会重置，得重新开。
