SQL Server简单SELECT查询性能问题求助

不用急着升级服务器，咱们先从几个低成本、易实施的方向排查优化，这类全表扫描的性能问题大多能通过调整解决：

1. 检查并修复聚集索引碎片 #

因为你的表用ID作为聚集索引，全表查询本质是扫描聚集索引。如果索引碎片过高，会大幅降低扫描效率。

• 用以下SQL查询索引碎片情况：

  SELECT 
      index_id, 
      index_type_desc, 
      avg_fragmentation_in_percent
  FROM sys.dm_db_index_physical_stats(
      DB_ID('DatabaseName'),
      OBJECT_ID('DatabaseName.dbo.TableName'),
      NULL,
      NULL,
      'DETAILED'
  )
  WHERE index_id = 1; -- 聚集索引的index_id固定为1
  

• 如果碎片率超过30%，直接重建索引：

  ALTER INDEX PK_TableName_ID ON [DatabaseName].[dbo].[TableName] REBUILD;
  

• 如果碎片率在10%-30%之间，重组索引即可：

  ALTER INDEX PK_TableName_ID ON [DatabaseName].[dbo].[TableName] REORGANIZE;
  

2. 排查IO瓶颈 #

全表扫描的性能很大程度依赖磁盘IO，你可以从这几点入手：

• 查看SQL Server的等待类型：如果发现大量PAGEIOLATCH_*（比如PAGEIOLATCH_SH）等待，说明磁盘读取速度跟不上。这时可以考虑把数据文件迁移到SSD存储，或者将表分散到多个数据文件（放在不同磁盘）来分摊IO压力。
• 开启快照隔离级别：默认的READ COMMITTED隔离级别可能会导致读操作被写操作阻塞，开启READ_COMMITTED_SNAPSHOT后，读操作会读取版本化数据，避免阻塞：

  ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON;
  

3. 避免不必要的SELECT * #

如果你的业务场景其实不需要返回所有4列，改成只查询需要的列。很多时候用户习惯写全列查询，但实际只用到部分数据——这种情况下，非聚集索引（比如CreateDate）可能能提供覆盖扫描，性能会比聚集索引扫描好得多。

4. 优化SQL Server内存配置 #

如果服务器内存不足，SQL Server会频繁将数据从磁盘加载到内存，又被迫换出，导致IO飙升：

• 检查SQL Server的内存使用情况：通过sys.dm_os_memory_clerks查看缓存命中率，或者在任务管理器中观察SQL Server的内存占用。如果内存使用率长期接近上限，且缓存命中率低于90%，可以调整SQL Server的最大内存设置（在SSMS的服务器属性-内存中修改），给SQL Server分配更多可用内存，让更多数据常驻缓存，后续查询速度会显著提升。

5. 更新统计信息 #

过期的统计信息会让查询优化器生成低效的执行计划。对于100万行的大表，建议用全扫描更新统计信息：

UPDATE STATISTICS [DatabaseName].[dbo].[TableName] WITH FULLSCAN;

最后再考虑服务器升级 #

如果以上所有优化都试过，性能还是达不到预期，再考虑升级服务器。优先升级内存（让更多数据缓存）或磁盘（换成更快的SSD），这两项对全表查询的提升比升级CPU更直接，成本也更低。

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