触发器内直接调用sp_send_dbmail可能失败，因其虽标称异步但实际仍绑定于未提交的用户事务，事务回滚时邮件无法发出，且易引发“the current transaction cannot be committed”错误。
触发器里直接调用 sp_send_dbmail 可能失败，原因是什么
SQL Server 的 AFTER INSERT 触发器默认运行在事务上下文中，而 sp_send_dbmail 是异步操作、内部会尝试提交自己的事务。如果触发器所在事务尚未提交（比如后续语句出错或显式回滚），邮件可能根本不会发出，甚至触发器报错：The current transaction cannot be committed and cannot support operations that write to the log file.
这不是配置问题，是 SQL Server 事务隔离机制决定的 —— sp_send_dbmail 不能安全嵌套在未完成的用户事务中。
可靠做法：把发邮件逻辑从触发器中剥离出来
最稳妥的方式是让触发器只做一件事：记录待告警的数据。真正发邮件由外部机制驱动，比如 SQL Server Agent 作业轮询、Service Broker 消息处理，或外部应用监听变更。
若必须“近实时”且环境受限（如无 Agent 权限），可采用以下折中方案：
- 触发器内仅插入一条记录到专用日志表（如
dbo.AlertQueue），字段至少含：id、table_name、inserted_data_json（用FOR JSON序列化）、created_at - 确保该日志表不参与业务主事务（例如用
SET XACT_ABORT OFF+TRY...CATCH包裹插入，并在CATCH中忽略错误） - 搭配一个低频（如每 10 秒）运行的 Agent 作业，执行
sp_send_dbmail并标记已处理（避免重复发送）
示例触发器片段（仅写队列表）：
CREATE TRIGGER tr_orders_after_insert ON dbo.Orders
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRY
INSERT INTO dbo.AlertQueue (table_name, inserted_data_json, created_at)
SELECT 'Orders', (SELECT * FROM inserted FOR JSON PATH, ROOT('data')), GETDATE();
END TRY
BEGIN CATCH
-- 忽略日志写入失败，不影响主业务
END CATCH
END;
如果坚持在触发器里调用 sp_send_dbmail，必须绕过事务绑定
技术上可行但风险高：用 EXECUTE AS LOGIN 切换到不受当前事务影响的上下文，并配合 COMMIT 提前结束当前事务分支 —— 但这会破坏原子性，且需极高权限（UNSAFE ASSEMBLY 或 db_owner），多数生产环境禁止。
更现实的“绕过”方式是启用 Service Broker 并发送消息，由激活存储过程异步处理邮件。但这要求：msdb 启用代理、sysmail 配置就绪、Service Broker 在目标库开启（ALTER DATABASE [YourDB] SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE），配置链路长，容易卡在任意一环。
发邮件内容怎么带插入数据？别拼接字符串
用 FOR JSON 或 FOR XML 安全序列化 inserted，避免 SQL 注入和特殊字符截断。不要用 CONCAT 拼接字段值，尤其当字段含换行、单引号或 NULL 时，邮件正文会乱或报错。
示例（安全取数据）：
DECLARE @body NVARCHAR(MAX) =
(SELECT 'New order: ' + CAST(order_id AS VARCHAR(10)) + ', amount: $' + CAST(amount AS VARCHAR(12))
FROM inserted
FOR JSON PATH, ROOT('alert'));
注意：FOR JSON 自动转义双引号、反斜杠等；若需纯文本而非 JSON，可用 STRING_AGG（SQL Server 2017+）配合 QUOTENAME 处理单字段值。
真正难的不是写触发器，而是让告警既及时又不拖垮业务事务。多数线上系统最终都弃用“触发器直发邮件”方案，转向变更捕获（CDC）或应用层埋点 —— 因为 DBA 很少允许你在核心表的 AFTER INSERT 里塞网络 I/O 操作。
