SQL Server Bulk Insert异常：临时表读取CSV旧值问题求助

兄弟，我之前做定时批量导入任务时也踩过几乎一模一样的坑！结合你说的「每5秒运行的Windows服务调用存储过程做Bulk Insert」这个场景，给你梳理几个最可能的原因和对应的解决办法，你可以逐个排查：

1. CSV文件未完全写入就被读取（最常见） #

很多时候问题根本不在SQL这边，而是Windows服务轮询太频繁，CSV文件还没被写入程序完全写完、释放句柄，服务就触发了Bulk Insert。这时候读的其实是文件的缓存版本或者未完成的内容，自然是旧值。

解决办法：

• 用文件重命名做"就绪标记"：让写入CSV的程序写完后，把文件从临时名称（比如data_temp.csv）重命名为服务监听的名称（比如data_ready.csv）。服务只扫描data_ready.csv，处理完成后立刻把文件移走或删除，避免重复读取。这种方式能100%确保读取的是完整的最新文件。
• 检查写入程序的文件句柄：如果写入程序是你自己开发的，确认写完后调用了File.Close()或者用using语句释放了文件资源，不然文件会被锁定，SQL的Bulk Insert可能读的是缓存的旧数据。

2. 临时表的作用域或残留问题 #

如果你的存储过程用了全局临时表（##temp_table），那麻烦就大了——全局临时表会在所有会话共享，如果前一次的服务调用没正常结束，新调用可能会读到上一次的旧数据。就算用了局部临时表，也可能因为异常情况导致临时表没被销毁。

解决办法：

• 立刻换成局部临时表（#temp_table）：局部临时表是会话隔离的，每次存储过程调用都会创建全新的表，完全不会和其他调用冲突。
• 存储过程开头强制清理临时表：在创建临时表前加一句判断，确保没有残留：

  IF OBJECT_ID('tempdb..#YourTempTable') IS NOT NULL
      DROP TABLE #YourTempTable;
  

3. 存储过程的执行计划缓存坑 #

如果你的CSV文件路径是动态的（比如每次都换文件名或路径），但存储过程里用了硬编码的路径，或者用了参数但没正确处理，SQL的执行计划缓存可能会让你每次都读同一个旧文件。

解决办法：

• 用动态SQL传递文件路径：Bulk Insert不直接支持参数化路径，所以得拼动态SQL执行：

  CREATE PROCEDURE dbo.YourBulkInsertProc
      @CsvFilePath NVARCHAR(500)
  AS
  BEGIN
      SET NOCOUNT ON;
      IF OBJECT_ID('tempdb..#TempImport') IS NOT NULL DROP TABLE #TempImport;
      CREATE TABLE #TempImport (...); -- 匹配CSV结构
  
      DECLARE @Sql NVARCHAR(MAX) = N'
          BULK INSERT #TempImport
          FROM ''' + REPLACE(@CsvFilePath, '''', '''''') + N'''
          WITH (
              FIELDTERMINATOR = '','',
              ROWTERMINATOR = ''\n'',
              FIRSTROW = 2
          )';
      EXEC sp_executesql @Sql;
  
      -- 后续处理逻辑
  END
  

  注意要替换路径里的单引号，避免SQL注入。
• 强制重新编译执行计划：如果还是有缓存问题，可以在执行存储过程时加WITH RECOMPILE，或者给存储过程加上这个选项（不过不建议全局加，会影响性能，只在必要时用）：

  EXEC dbo.YourBulkInsertProc @CsvFilePath = 'C:\data\new.csv' WITH RECOMPILE;
  

4. Windows服务进程的文件缓存 #

有些时候，Windows服务进程会对读取过的文件做缓存，就算磁盘上的文件更新了，进程还是读的缓存里的旧内容。

解决办法：

• 在服务读取文件（或者触发存储过程）前，手动刷新文件缓存。如果是C#写的服务，可以用File.Open时指定FileOptions.SequentialScan和FileShare.ReadWrite参数，强制读取磁盘最新内容：

  using (var stream = new FileStream(csvPath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite, 4096, FileOptions.SequentialScan))
  {
      // 这里可以先验证文件内容，再调用存储过程
  }
  

调试小技巧 #

• 给服务和存储过程加日志：每次执行时，记录CSV文件的最后修改时间、存储过程执行时间、临时表的行数和前几条数据，这样能快速定位是文件没更新，还是Bulk Insert读错了。
• 手动测试：暂停服务，手动更新CSV文件，然后直接在SSMS里执行存储过程，看能不能读到最新值。如果可以，那问题肯定在服务的触发逻辑或文件读取环节；如果不行，再排查存储过程本身。

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