如何加速SQL Server Enterprise中大表的COUNT查询？

嘿，针对你碰到的这个供应商应用里COUNT查询拖慢财务单据处理的问题，结合SQL Server Enterprise的特性，我给你几个实战性的优化方向：

1. 先确认现有极窄非聚集索引是否真的在干活 #

你提到已经建了极窄非聚集索引，首先得搞清楚SQL Server是不是真的用它来执行SELECT COUNT('A') FROM [dbo].[Items] T0这个查询。毕竟COUNT('A')本质和COUNT(*)逻辑一致——都是统计存在的行数，只要索引是仅包含非空固定长度列（比如主键列、bit列这类），理论上它应该是最优的扫描对象，因为页数最少。

• 验证方法：执行SET SHOWPLAN_XML ON;然后跑你的COUNT查询，查看执行计划里的索引扫描对象是不是你建的那个非聚集索引。
• 如果没用到，大概率是统计信息过时或者索引有碎片：
  • 更新统计信息：UPDATE STATISTICS [dbo].[Items];
  • 重建索引：ALTER INDEX [你的索引名称] ON [dbo].[Items] REBUILD;

2. 利用SQL Server Enterprise专属工具定位问题 #

• 查询存储（Query Store）：如果还没开，先开启它：ALTER DATABASE [你的数据库名] SET QUERY_STORE = ON;。之后找到这个COUNT查询的执行计划，它会直接给出索引选择不佳、统计信息过期这类的优化建议，非常直观。
• 数据库引擎优化顾问（DTA）：把这个COUNT查询导入进去，它会基于你的表结构和数据分布给出针对性的索引或统计信息调整建议——不过别盲目照搬，要结合业务场景判断是否合理。

3. 小调整：改用COUNT_BIG(*)替代COUNT('A') #

虽然COUNT('A')和COUNT(*)功能完全一致，但COUNT_BIG(*)返回bigint类型，对于超大规模表更友好。而且在部分并行查询场景下，SQL Server对它的处理会有微小的性能提升，对你600万行的表来说影响不大，但可以作为一个规范调整，避免后续数据量增长后出现溢出问题。

4. 预计算行数（适合允许最终一致性的场景） #

如果业务不需要实时的精确行数，或者可以接受短时间的延迟，这招能直接把400ms的耗时砍到几ms：

• 近似值快速获取：用系统视图读取SQL Server维护的分区统计信息：

  SELECT SUM(row_count) 
  FROM sys.dm_db_partition_stats 
  WHERE object_id = OBJECT_ID('[dbo].[Items]') 
    AND index_id < 2;
  

  这个结果是近似值，有小误差，但速度极快。
• 精确值预存储：创建一个小表（比如dbo.TableRowCounts），用定时作业（SQL Server Agent）定期计算Items表的行数并更新进去，应用直接查询这个小表即可。如果需要更实时的更新，可以配合触发器（但要注意触发器对写性能的影响）。

5. 排查锁与阻塞问题 #

有时候COUNT查询慢不是因为扫描本身，而是被其他写操作（比如订单、发票的插入/更新）阻塞了：

• 检查阻塞：用sp_who2或者查询sys.dm_tran_locks视图，看看查询执行时有没有被其他事务锁住。
• 解决阻塞：可以开启快照隔离，把查询的隔离级别改成READ COMMITTED SNAPSHOT：
  1. 先开启数据库快照隔离：ALTER DATABASE [你的数据库名] SET ALLOW_SNAPSHOT_ISOLATION ON;
  2. 查询时设置：SET TRANSACTION ISOLATION LEVEL READ COMMITTED SNAPSHOT;
     这样查询不会阻塞写操作，也不会被写操作阻塞，只是会增加一点tempdb的开销，对Enterprise版本来说完全可控。

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