你的问题核心根本不是“让出控制权”——SQL Server的DML触发器是同步执行的：在你的DELETE语句执行完成之前，对应的触发器就已经跑完了，审计记录早就写入AUDIT_TRAIL表了。你遇到的更新失败，大概率是当前代码的查询条件逻辑有缺陷，或是时间戳精度导致的匹配问题。

最优解决方案：让触发器直接获取执行者（彻底避免后续更新） #

与其在DELETE后再去补更新审计记录，不如直接在触发器里拿到删除操作的执行者，一步到位写入changed_by。这里分两种场景处理：

场景1：存储过程用当前登录用户执行 #

如果@delUser就是执行存储过程的SQL登录用户，触发器里直接用系统函数就能拿到用户名：

-- 示例触发器（替换成你的实际逻辑）
CREATE TRIGGER trg_YourTable_Delete ON dbo.YourTable
AFTER DELETE
AS
BEGIN
    SET NOCOUNT ON;
    INSERT INTO AUDIT_TRAIL (table_name, table_pk_value, changed_at, changed_by, operation_type)
    SELECT 
        'YourTable',
        deleted.PKColumn,
        SYSDATETIME(),
        ORIGINAL_LOGIN(), -- 直接获取发起操作的登录用户
        'DELETE'
    FROM deleted;
END

场景2：@delUser是传入的业务用户（非SQL登录账户） #

如果存储过程是用服务账户执行的，@delUser是业务系统的用户名，可以用CONTEXT_INFO把用户名传递给触发器：

修改存储过程的DELETE部分：

BEGIN TRANSACTION;
-- PART 1: DO THE DELETE:
-- 把业务用户名写入CONTEXT_INFO，传递给触发器
DECLARE @context VARBINARY(128) = CAST(@delUser AS VARBINARY(128));
SET CONTEXT_INFO @context;

DECLARE @DELETION_TEMPLATE AS VARCHAR(MAX);
SET @DELETION_TEMPLATE = 'delete from {THE_TABLE_NAME} WHERE {PK_ID_COL_NAME} = {PK_ID_VALUE}';
SET @DELETION_TEMPLATE = REPLACE(@DELETION_TEMPLATE, '{THE_TABLE_NAME}', @tableName);
SET @DELETION_TEMPLATE = REPLACE(@DELETION_TEMPLATE, '{PK_ID_COL_NAME}', @pkIDColName);
SET @DELETION_TEMPLATE = REPLACE(@DELETION_TEMPLATE, '{PK_ID_VALUE}', @pkIDValue);
EXEC (@DELETION_TEMPLATE);

-- 清除CONTEXT_INFO，避免影响后续操作
SET CONTEXT_INFO 0x0;
COMMIT TRANSACTION;

修改触发器：

CREATE TRIGGER trg_YourTable_Delete ON dbo.YourTable
AFTER DELETE
AS
BEGIN
    SET NOCOUNT ON;
    -- 从CONTEXT_INFO中读取传入的业务用户名
    DECLARE @delUser VARCHAR(100) = CAST(NULLIF(CONTEXT_INFO(), 0x0) AS VARCHAR(100));
    
    INSERT INTO AUDIT_TRAIL (table_name, table_pk_value, changed_at, changed_by, operation_type)
    SELECT 
        'YourTable',
        deleted.PKColumn,
        SYSDATETIME(),
        ISNULL(@delUser, ORIGINAL_LOGIN()), -- 兜底用SQL登录用户
        'DELETE'
    FROM deleted;
END

这样触发器生成审计记录时直接写入changed_by，完全不需要后续的更新操作，从根源上解决问题。

如果你一定要保留“先删除再更新”的逻辑 #

那需要修复查询条件的缺陷，解决时间戳匹配问题：

问题点分析 #

1. 时间戳精度问题：你用CONVERT(varchar, SYSDATETIME(), 121)把时间转成毫秒级字符串，但SYSDATETIME()本身是7位小数精度（比如2024-05-20 14:30:00.1234567），转换后会丢失小数位，若触发器里的changed_at是原始精度，可能导致匹配失败。
2. 动态SQL类型不安全：直接拼接@pkIDValue到SQL语句中，如果table_pk_value是字符串类型，会因缺少引号导致语法错误或匹配失败。

修复后的更新逻辑 #

改用参数化查询避免SQL注入，同时用时间范围代替精确匹配：

BEGIN TRANSACTION;
-- PART 2: UPDATE THE AUDIT_TRAIL:
DECLARE @TOTAL_NUM_ROWS_UPDATED_WITH_USERNAME AS NUMERIC;
SET @TOTAL_NUM_ROWS_UPDATED_WITH_USERNAME = 0;

-- 取删除前后10毫秒的时间范围，避免精度问题
DECLARE @startTime DATETIME2 = DATEADD(MILLISECOND, -10, SYSDATETIME());
DECLARE @endTime DATETIME2 = DATEADD(MILLISECOND, 10, SYSDATETIME());

DECLARE @UPDATE_AUDIT_TRAIL_TEMPLATE AS NVARCHAR(MAX);
SET @UPDATE_AUDIT_TRAIL_TEMPLATE = N'
UPDATE AUDIT_TRAIL 
SET changed_by = @delUser
WHERE UPPER(table_name) = UPPER(@tableName)
  AND table_pk_value = @pkIDValue
  AND changed_at BETWEEN @startTime AND @endTime
  AND changed_by IS NULL -- 只更新未设置的记录
';
-- 使用sp_executesql做参数化查询，避免类型问题和SQL注入
EXEC sp_executesql 
    @UPDATE_AUDIT_TRAIL_TEMPLATE,
    N'@delUser VARCHAR(100), @tableName VARCHAR(100), @pkIDValue NUMERIC, @startTime DATETIME2, @endTime DATETIME2',
    @delUser = @delUser,
    @tableName = @tableName,
    @pkIDValue = @pkIDValue,
    @startTime = @startTime,
    @endTime = @endTime;

SELECT @TOTAL_NUM_ROWS_UPDATED_WITH_USERNAME = @@ROWCOUNT;
COMMIT TRANSACTION;
RETURN @TOTAL_NUM_ROWS_UPDATED_WITH_USERNAME;

为什么循环等待没用？ #

再强调一次：SQL Server的AFTER触发器是同步执行的，你的DELETE语句执行完毕时，触发器已经完成了审计记录的插入操作。等待完全是多余的，问题根本不在触发器的执行时机上，而是你的查询条件或数据匹配逻辑有漏洞。

内容的提问来源于stack exchange，提问作者fandang