SQL Server中唯一原生事务安全的异步机制是Service Broker，需启用数据库级SSB、创建消息类型/契约/队列/服务，通过BEGIN DIALOG+SEND发送序列化参数，并由激活存储过程自动处理。
不能在存储过程内部真正“异步执行”——所有主流数据库都不支持在单个会话里 fork 子线程或启动后台任务。所谓“异步”，本质是把耗时逻辑剥离出当前事务，靠外部机制接力处理。
SQL Server：用 Service Broker 实现事务安全的真异步
Service Broker（SSB）是 SQL Server 唯一原生、持久化、事务一致的异步消息机制。它不依赖 SQL Agent，也不阻塞调用方。
- 必须先启用数据库级 SSB：
ALTER DATABASE [YourDB] SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE，缺这步SEND会直接报错 - 最小四件套不可少：
CREATE MESSAGE TYPE、CREATE CONTRACT、CREATE QUEUE、CREATE SERVICE；契约没配对会导致对话失败 - 发送端必须用
BEGIN DIALOG获取句柄，再SEND ON CONVERSATION，跳过对话直接发会报The conversation endpoint is in an error state - 消息体只能是
VARBINARY(MAX)，参数得序列化：CAST((SELECT @ID FOR JSON PATH) AS VARBINARY(MAX)) - 发送后必须
COMMIT，否则会话回滚；别在同一个事务里RECEIVE，那是同步反模式
PostgreSQL：靠 dblink_send_query 发起即返回
NOTIFY 不是异步执行方案，它只发通知、不执行逻辑、不持久、不跨连接。真要“发起即走”，dblink_send_query 是唯一可行的 PL/pgSQL 内建方式。
- 先装扩展：
CREATE EXTENSION dblink，否则函数不存在 - 连接串里别硬编码密码，用
.pgpass或连接参数password=xxx控制安全 -
dblink_send_query提交后立即返回，但结果得靠dblink_get_result轮询获取（或干脆忽略） - 不适合高频短任务——每个调用都新建 backend 进程，连接开销大；并发高时容易打满
max_connections - 若需可靠执行，仍得配合任务表 + 外部轮询，
dblink只解决“不卡住当前函数”这一步
MySQL：消息队列是唯一可控路径
MySQL 官方禁用所有系统命令执行函数。sys_exec 是第三方 UDF，生产环境基本被禁用，且极不安全。
- 别碰
SYS_EVAL、sys_exec、lib_mysqludf_sys等扩展，审计和安全部门第一眼就会拒掉 - 写入消息到外部队列（如
Redis Stream、RabbitMQ、Kafka）是唯一通用解法 - 存储过程里只做一件事：
INSERT INTO task_queue (payload, status) VALUES (@json, 'pending') - 消费者进程独立部署，负责拉取、执行、更新状态；失败重试、幂等、死信都要自己实现
- 注意
task_queue表的status字段必须有索引，否则轮询WHERE status = 'pending'会全表扫
容易被忽略的共性陷阱
所有方案都绕不开一致性与可观测性问题。最常被跳过的点是：没有状态字段、没设超时、不记录错误上下文。
- 任务表或消息体里必须带
created_at和updated_at，否则无法识别卡死任务 - 别依赖“执行完就消失”的乐观假设——网络抖动、消费者崩溃、权限变更都会让任务悬停
- SQL Server Agent 的
sp_start_job是伪异步：调用返回快，但作业失败不会通知调用方，得查msdb.dbo.sysjobhistory - Oracle 的
DBMS_JOB在 19c+ 已标记为 deprecated，新项目应迁移到DBMS_SCHEDULER，且管道（DBMS_PIPE）不跨会话，监控端必须长连接
