SQL Server存储过程显示执行成功但内部查询未执行的问题排查

我之前在维护依赖链接服务器的ETL管道时，碰到过几乎一模一样的问题——存储过程返回成功但内部DML啥也没干，手动跑存储过程没用，但单独拎出查询却能正常执行，日志里还啥错误都没有。结合你的描述和代码，咱们拆解下可能的原因，再给出针对性的解决办法：

可能的根源 #

1. 执行计划缓存“跑偏” #

这和你猜测的方向一致。当存储过程的执行计划被缓存后，如果链接服务器端的统计信息发生变化，或者本地与远端的统计数据不匹配，生成的执行计划可能会错误地认为没有匹配的行，导致DML操作静默跳过（0行受影响），但这不属于错误，所以TRY/CATCH不会触发，日志自然没记录。而手动执行查询时，SQL Server会生成新的执行计划，能正确匹配到数据，所以能正常执行。

2. Agent作业的上下文环境差异 #

手动执行和SQL Server Agent作业的执行上下文可能不一样——比如ANSI_NULLS、QUOTED_IDENTIFIER这类SET选项，或者作业账号的链接服务器权限临时波动。举个例子，如果Agent的ANSI_NULLS是OFF，而你的JOIN条件涉及NULL判断，就可能导致匹配逻辑失效，DML没找到要操作的行，但这同样不是错误，不会被捕获。

3. 链接服务器会话的隐性异常 #

推送式链接服务器依赖跨服务器会话，有时候Agent作业的连接池可能会复用一个失效的会话，导致存储过程里的DML操作实际上没发送到远端服务器，但本地SQL Server却认为执行成功了——这种情况比较隐蔽，日志里也不会有错误。

针对性解决办法 #

1. 强制刷新执行计划，干掉缓存问题 #

最简单的办法是给每个跨服务器的DML语句加上OPTION (RECOMPILE)，让SQL Server每次执行都重新生成执行计划，避免旧计划的坑：

-- DELETE语句示例
DELETE at
FROM LINKED_SERVER.ANOTHER_DB.dbo.another_table AS at
LEFT JOIN SOME_DB.dbo.some_table AS st
    ON st.some_table_id = at.some_table_id
WHERE st.some_table_id IS NULL
OPTION (RECOMPILE);

-- UPDATE和INSERT语句同理，都加上这个选项

如果不想每个语句都加，也可以在存储过程开头加上DBCC FREEPROCCACHE (OBJECT_ID('dbo.some_etl_proc'));（注意：只清除该存储过程的缓存，不会影响其他对象），或者用WITH RECOMPILE创建存储过程，但后者每次执行都会编译，可能影响性能，适合你这种偶尔出问题的场景。

2. 对齐Agent和手动执行的上下文 #

在存储过程开头显式设置关键的SET选项，避免环境差异：

SET NOCOUNT ON;
SET XACT_ABORT ON;
SET ANSI_NULLS ON;
SET QUOTED_IDENTIFIER ON;
-- 其他必要的SET选项，比如ANSI_PADDING ON等

同时可以加个日志，记录每次执行的上下文参数，方便排查：

INSERT INTO dbo.etl_context_log
SELECT 
    GETDATE(),
    OBJECT_NAME(@@PROCID),
    SESSIONPROPERTY('ANSI_NULLS'),
    SESSIONPROPERTY('QUOTED_IDENTIFIER'),
    SYSTEM_USER;

对比手动执行和Agent执行时的日志，就能快速发现环境差异。

3. 给DML加执行日志，搞清楚是“没执行”还是“没匹配到行” #

在每个DML操作后记录受影响的行数，这样下次出问题时，就能知道是真的没执行，还是逻辑上没有匹配的行：

DECLARE @delete_rows INT, @update_rows INT, @insert_rows INT;

-- DELETE操作
DELETE at
FROM LINKED_SERVER.ANOTHER_DB.dbo.another_table AS at
LEFT JOIN SOME_DB.dbo.some_table AS st
    ON st.some_table_id = at.some_table_id
WHERE st.some_table_id IS NULL;
SET @delete_rows = @@ROWCOUNT;

-- UPDATE操作
UPDATE at
SET col_1 = st.col_1, col_2 = st.col_2
FROM LINKED_SERVER.ANOTHER_DB.dbo.another_table AS at
JOIN SOME_DB.dbo.some_table AS st
    ON st.some_table_id = at.some_table_id;
SET @update_rows = @@ROWCOUNT;

-- INSERT操作
INSERT INTO LINKED_SERVER.ANOTHER_DB.dbo.another_table (col_1, col_2)
SELECT st.col_1, st.col_2
FROM SOME_DB.dbo.some_table AS st
LEFT JOIN LINKED_SERVER.ANOTHER_DB.dbo.another_table AS at
    ON at.some_table_id = st.some_table_id
WHERE at.some_table_id IS NULL;
SET @insert_rows = @@ROWCOUNT;

-- 记录日志
INSERT INTO dbo.etl_operation_log
SELECT 
    GETDATE(),
    OBJECT_NAME(@@PROCID),
    'DELETE', @delete_rows,
    'UPDATE', @update_rows,
    'INSERT', @insert_rows;

如果日志里显示三个操作的行数都是0，那就是逻辑匹配的问题；如果行数是NULL或者异常值，那可能是执行本身出了问题。

4. 切换拉取策略时的优化（从根源解决） #

既然你们已经在切换到拉取策略，建议把跨服务器的DML改成先拉数据到本地临时表，再做操作，减少跨服务器交互的风险：

BEGIN TRY
    -- 把远端数据拉到本地临时表
    SELECT * INTO #temp_remote_data
    FROM LINKED_SERVER.ANOTHER_DB.dbo.another_table;

    -- 用MERGE语句合并三个操作，更简洁也更易排查
    MERGE INTO LINKED_SERVER.ANOTHER_DB.dbo.another_table AS target
    USING SOME_DB.dbo.some_table AS source
    ON target.some_table_id = source.some_table_id
    WHEN MATCHED THEN 
        UPDATE SET col_1 = source.col_1, col_2 = source.col_2
    WHEN NOT MATCHED BY TARGET THEN 
        INSERT (col_1, col_2) VALUES (source.col_1, source.col_2)
    WHEN NOT MATCHED BY SOURCE THEN 
        DELETE;
END TRY

MERGE把三个DML合并成一个跨服务器操作，减少会话交互次数，也更容易追踪执行情况。

5. 增强异常检测，捕获“静默失败” #

因为0行受影响不属于错误，TRY/CATCH不会触发，所以可以在存储过程末尾加个检查，如果所有DML的受影响行数总和为0，就记录警告：

IF (@delete_rows + @update_rows + @insert_rows) = 0
BEGIN
    INSERT INTO dbo.etl_warning_log
    SELECT 
        GETDATE(),
        OBJECT_NAME(@@PROCID),
        'No rows were affected by any DML operation - this may be an abnormal case';
    -- 可选：抛出警告，让Agent作业标记为警告状态
    RAISERROR('ETL operation completed but no rows were affected', 10, 1);
END

这样即使没有错误，也能及时发现异常情况。

总结 #

结合你的情况，执行计划缓存不匹配或者Agent上下文差异的概率最高。先尝试给DML语句加OPTION (RECOMPILE)，同时添加执行日志，应该能快速定位并解决问题。另外，尽快切换到拉取策略，能从根源上减少这类跨服务器的隐性问题。

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