如何加速Azure SQL中4.4万条记录的MERGE语句？

核心问题 #

将JSON数据加载到表变量后执行MERGE操作，目标表共14.4万条记录，筛选4.4万条进行MERGE时，Azure SQL按需付费实例耗时4秒，而本地SQL Server仅需0.5秒，性能差异显著。

关键原因分析 #

1. 表变量缺少统计信息
   表变量@ChannelReadings（原代码中MERGE使用的@tt疑似笔误）无统计信息，SQL优化器无法准确预估其中的数据量，易生成低效执行计划。本地环境可能因资源充足或数据量预估巧合，计划更优；而Azure上因预估偏差，可能触发不必要的哈希匹配、排序等操作，拉高耗时。

2. Azure SQL按需付费的资源限制
   按需付费（Serverless）模式下，数据库动态调整资源配额，但冷启动、资源扩容延迟或当前会话配额不足时，CPU、内存、IO等资源受限，直接拖慢执行速度。本地SQL Server为固定资源配置，无此类限制。

3. MERGE操作的固有开销
   MERGE需同时完成匹配检查与插入操作，逻辑复杂度高于单独的INSERT+NOT EXISTS。加上目标表的非聚集索引虽基于ReadingDateTime，但表变量数据未排序时，匹配阶段需额外排序，进一步增加Azure上的资源消耗。

4. JSON解析的潜在损耗
   从ChannelReadingJSON读取JSON并解析到表变量的过程，在Azure上可能因内存带宽限制，效率低于本地环境，间接拉长整体耗时。

优化措施 #

• 替换表变量为临时表
  临时表（#ChannelReadings）会自动生成统计信息，优化器能精准预估数据分布，生成更高效的执行计划。替换后MERGE的匹配阶段效率会明显提升。

• 手动更新表变量统计信息（若坚持用表变量）
  在INSERT表变量后执行：

  UPDATE STATISTICS @ChannelReadings;
  

  帮助优化器获取准确的数据量与分布。

• 调整Azure SQL按需付费配置
  设置最小vCore数，避免冷启动资源不足；执行操作前提前唤醒数据库，确保资源已完成分配。

• 用INSERT+NOT EXISTS替代MERGE
  MERGE在部分场景下开销较高，改用以下语句可简化逻辑、降低开销：

  INSERT INTO [ChannelReading_939029_11_F0EA4CCA-3522-4175-AA53-83563F91235F]
    (ReadingDateTime, SIReading, RawReading)
  SELECT 
    S.ReadingDateTime, S.SIReading, S.RawReading
  FROM (
    SELECT 
      [Si] AS SIReading,
      [Raw] AS RawReading,
      [TimeStamp] AS ReadingDateTime
    FROM @ChannelReadings
    WHERE ChannelID = 11  -- 匹配tinyint类型，无需引号
  ) S
  WHERE NOT EXISTS (
    SELECT 1 
    FROM [ChannelReading_939029_11_F0EA4CCA-3522-4175-AA53-83563F91235F] T
    WHERE T.ReadingDateTime = S.ReadingDateTime
  );
  

• 优化JSON读取与解析
  为ChannelReadingJSON表创建SerialNumber+TimeStamp的复合索引，加速JSON数据读取；统一OPENJSON与表变量的字段类型（比如DeviceSerialNumber的长度），减少隐式转换开销。

• 整理目标表索引碎片
  执行以下语句修复索引碎片，降低IO开销：

  ALTER INDEX [NonClusteredIndex-20230403-100008] 
  ON [dbo].[ChannelReading_939029_11_F0EA4CCA-3522-4175-AA53-83563F91235F] 
  REORGANIZE;
  

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