Azure SQL S0实例小表简单SQL查询频繁超时问题求助

可能的原因及解决思路： #

• 缺失idItem字段的索引：
  你的查询基于idItem做等值匹配，哪怕表只有2500条记录，无索引时会触发全表扫描。S0实例DTU资源有限，首次查询无缓存加持，全表扫描会直接耗尽DTU导致超时；后续依赖缓存速度略提升，但依然远低于正常水平。建议给idItem创建包含查询字段的非聚集索引：

  CREATE NONCLUSTERED INDEX IX_ItemReports_idItem ON dbo.ItemReports(idItem)
  INCLUDE (severity, text); -- 直接包含返回字段，避免额外键查找开销
  

• 未使用参数化查询：
  代码直接拼接testcase.Id到SQL语句中，会导致SQL Server无法复用执行计划，每次查询都要重新编译。在S0这种资源紧张的实例上，编译开销会被放大，进一步拖慢速度。改成参数化写法：

  using (var connection = new SqlConnection(SelectConnectionForm.ConnectionString))
  {
      connection.Open();
      var command = new SqlCommand(
          "SELECT TOP(10) CAST(severity AS int )AS severity,text FROM [dbo].[ItemReports] WHERE idItem=@idItem", 
          connection);
      command.Parameters.AddWithValue("@idItem", testcase.Id);
      using (var reader = command.ExecuteReader())
      {
          while (reader.Read())
          {
              var node = (string)reader["text"];
              // Do Stuff with node    
          }
      }
  }
  

  另外用using包裹SqlDataReader，无需手动Close，会自动释放资源。

• 表/索引碎片过多：
  夜间构建频繁写入数据，可能导致表或索引产生大量碎片，增加扫描时的IO开销。可以执行以下语句检查碎片率：

  SELECT 
      name,
      avg_fragmentation_in_percent
  FROM sys.dm_db_index_physical_stats(
      DB_ID(), OBJECT_ID('dbo.ItemReports'), NULL, NULL, 'DETAILED'
  );
  

  碎片率超30%时重建索引，10%-30%之间重组索引即可。

• 执行计划过时：
  可能存在适配旧数据量的过时执行计划（比如之前表数据量大时生成的计划，现在数据量缩小但计划未更新）。可在低峰期清除缓存计划：

  DBCC FREEPROCCACHE; -- 注意：会清除所有缓存计划，需谨慎操作
  

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