SQL Server 用 Service Broker 可实现存储过程内“发完就走”的可靠异步，需启用 ENABLE_BROKER、配置队列激活及 JSON 序列化；PostgreSQL 应用任务表+外部轮询，MySQL 避免存储过程内轮询或 WAITFOR。
SQL 存储过程本身无法真正异步执行任务——所谓“异步触发 + 轮询”，本质是把同步阻塞拆成两段：一段快速返回（触发），一段由外部或后台机制承担（轮询或消费）。直接在存储过程中写 WHILE 循环查状态，仍是同步阻塞，且极易锁表、耗连接、超时失败。
SQL Server 用 Service Broker 触发后不等，靠激活过程处理
Service Broker 是唯一能从存储过程里“发完就走”且保证消息不丢的机制。关键不是 SEND 后自己查，而是让队列自动唤起存储过程处理。
- 必须先启用数据库级 SSB：
ALTER DATABASE [YourDB] SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE，否则SEND直接报错Service Broker is not enabled - 发送端不要自己
RECEIVE，那是反模式；队列要配ACTIVATION：CREATE QUEUE MyQueue WITH ACTIVATION (STATUS = ON, PROCEDURE_NAME = dbo.usp_HandleMsg, EXECUTE AS OWNER) - 消息体必须序列化为
VARBINARY(MAX)，别传表变量；简单参数推荐：CAST((SELECT @ID, @Action FOR JSON PATH) AS VARBINARY(MAX)) - 发送后务必
COMMIT，否则会话回滚，消息进不了传输队列sys.transmission_queue
PostgreSQL 用任务表 + 外部轮询，别碰 NOTIFY/LISTEN
NOTIFY 只在当前连接生命周期内有效，应用重启或网络抖动就丢事件，不能当异步触发器用。
- 建一张任务表，至少含字段：
id、status（'pending'/'running'/'done'/'failed'）、created_at、updated_at、payload JSONB - 存储过程只做插入：
INSERT INTO task_queue (status, payload) VALUES ('pending', jsonb_build_object('order_id', $1)); - 外部守护进程（如 Python +
psycopg2）定时查：SELECT * FROM task_queue WHERE status = 'pending' LIMIT 1 FOR UPDATE SKIP LOCKED - 轮询间隔别低于 5 秒；太密会打满连接池，也容易撞上事务隔离导致重复取同一行
轮询逻辑必须带状态机和幂等控制
没有状态字段和更新时间戳的“轮询”，等于裸奔。你根本分不清是卡住了、失败了，还是刚启动。
- 状态变更必须原子：
UPDATE task_queue SET status = 'running', updated_at = NOW() WHERE id = $1 AND status = 'pending'，靠返回影响行数判断是否抢到任务 - 加超时兜底：比如
WHERE status = 'running' AND updated_at < NOW() - INTERVAL '10 minutes'，可识别死锁或崩溃未清理的任务 - 避免“查-改-再查”式轮询：每次轮询应完成一次完整状态跃迁（pending → running → done/failed），而不是反复读同一行
- MySQL 的
EVENT不适合轮询状态，它只负责定时调用，没法感知任务实际进度；真要轮询，得另起应用进程
别在存储过程中写 WAITFOR DELAY 或循环等待
这是最常见也最危险的误区。它不解决异步问题，只是把阻塞从客户端移到服务端，还更容易拖垮整个实例。
-
WAITFOR DELAY '00:00:05'只暂停当前会话，连接一断，后续逻辑全丢；重连后也不会自动续跑 - 循环查表（如
WHILE (SELECT status FROM task WHERE id=@id) = 'pending'）会持续占着事务、锁住行、吃 CPU，且 SQL Server 默认LOCK_TIMEOUT是 -1（无限等） - 想“模拟异步”不如直接用 SQL Server Agent 创建作业，或者把逻辑提到应用层用
SqlCommand.BeginExecuteNonQuery()发起异步调用
真正的难点不在怎么发，而在怎么确保“发出去就真有人收、收了就真能做、做了就真能记账”。状态字段设计、消息序列化方式、外部进程存活管理——这些细节漏一个，整条链路就不可靠。
