SQL Server触发器必须同步执行且不能异步，真正的异步需依赖Service Broker：触发器仅负责轻量发消息（BEGIN DIALOG + SEND），由激活存储过程异步处理；严禁在触发器中执行耗时操作。

SQL Server 触发器本身不能异步执行任何逻辑——它必须在主事务内完成，否则会阻塞 INSERT/UPDATE/DELETE。真能落地的“异步”，靠的是 Service Broker 把变更消息甩出去，让独立存储过程后续处理。

触发器里只能做三件事：建对话、发消息、不报错

触发器不是干活的地方，是“发单子”的窗口。它必须轻量、快速、失败可忽略（否则卡住主表写入）。常见错误是试图在触发器里解析 JSON、查远程表、调 HTTP 接口——这些全都不允许。

• 必须用 BEGIN DIALOG CONVERSATION 获取句柄，再 SEND ON CONVERSATION；跳过对话直接 SEND 会报错 The conversation endpoint is not found
• 消息体必须是 VARBINARY(MAX)，推荐用 CAST((SELECT * FROM inserted FOR JSON PATH, WITHOUT_ARRAY_WRAPPER) AS VARBINARY(MAX)) 序列化
• 不要在触发器里 WAITFOR (RECEIVE ...) ——那是同步反模式，会锁死当前会话
• 若 SEND 失败（比如队列不存在或契约不匹配），整个触发器事务会回滚，主 DML 也失败；所以务必提前验证对象链完整

Service Broker 对象链缺一不可，顺序不能乱

Service Broker 不是开关一开就能用，它是一套依赖严格的基础设施。漏建任意一个，消息就卡在 sys.transmission_queue 里不动，且不报明显错误。

• 先启用数据库：ALTER DATABASE YourDB SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE（注意加 WITH ROLLBACK IMMEDIATE，否则可能被连接阻塞）
• 按顺序创建：MESSAGE TYPE → CONTRACT → QUEUE → SERVICE；CONTRACT 必须引用已存在的 MESSAGE TYPE，SERVICE 必须绑定到已存在的 QUEUE 和 CONTRACT
• 跨实例场景还得多三步：CREATE MASTER KEY + CREATE CERTIFICATE（导出/导入公钥）、CREATE ROUTE（ADDRESS 必须写对方真实 IP+端口，不能写 localhost）、CREATE REMOTE SERVICE BINDING
• 检查是否就绪：SELECT is_broker_enabled FROM sys.databases WHERE name = 'YourDB'；查消息堆积：SELECT * FROM sys.transmission_queue

激活存储过程才是干活的人，得自己管生命周期

没人手动去 RECEIVE，消息才叫“异步”。靠的是队列的 ACTIVATION 属性自动拉起存储过程——但它不会自动帮你收尾，不处理会话终结，消息就会一直占着资源。

• 创建队列时必须指定 ACTIVATION：CREATE QUEUE Q_Sync WITH ACTIVATION (STATUS = ON, PROCEDURE_NAME = [usp_ProcessSync], MAX_QUEUE_READERS = 4, EXECUTE AS OWNER)
• 激活过程里必须用 WAITFOR (RECEIVE ...) 循环读取，每次 RECEIVE 后要 END CONVERSATION @h 或 MOVE CONVERSATION @h TO [new_queue]，否则会话状态卡在 CONVERSING
• 必须捕获错误并 END CONVERSATION @h WITH CLEANUP，否则失败会话持续占用会话 ID，最终耗尽系统会话资源
• 别在激活过程中做重试逻辑——SSB 自带重发机制；重点是把消息体反序列化后交由业务逻辑处理，失败则记录日志、丢进死信表

为什么不用轮询临时表或 WAITFOR DELAY 模拟异步

因为它们根本不是异步，只是把阻塞从“毫秒级”拖成“秒级”，还引入竞态和资源泄漏风险。Service Broker 是唯一被 SQL Server 官方支持、事务安全、持久化、可监控的异步原语。

• WAITFOR DELAY 会让触发器线程挂起，主事务长时间持有锁，极易引发死锁和超时
• 轮询临时表或普通表需要额外锁控制，且无法保证消息不丢失、不重复；而 SSB 消息写入即持久化，即使 SQL Server 重启也不会丢
• SSB 提供完整可观测性：sys.service_queues 查积压、sys.conversation_endpoints 查会话状态、sys.transmission_queue 查发送失败原因
• 性能上，一次 SEND 是微秒级操作；而远程调用、HTTP 请求、甚至跨库查询，都是毫秒到秒级，完全不在一个量级

最易被忽略的点是：Service Broker 的会话（conversation）不是“发完就结束”，它是有状态的长连接抽象。哪怕你只发一条消息，也得显式 END CONVERSATION，否则它永远留在系统视图里，堆积多了会导致 sys.conversation_endpoints 膨胀、查询变慢、甚至影响新会话创建。