小编Tif*_*nyP的帖子

我们有一个大约 1TB 的大型数据库，在强大的服务器上运行 SQL Server 2014。几年来，一切都运行良好。大约 2 周前，我们进行了全面维护，其中包括： 安装所有软件更新；重建所有索引和压缩 DB 文件。但是，我们没想到在某个阶段，在实际负载相同的情况下，DB 的 CPU 使用率会增加超过 100% 到 150%。

经过大量的故障排除，我们将其缩小到一个非常简单的查询，但我们找不到解决方案。查询非常简单：

select top 1 EventID from EventLog with (nolock) order by EventID

它总是需要大约 1.5 秒！但是，使用“desc”的类似查询总是需要大约 0 毫秒：

select top 1 EventID from EventLog with (nolock) order by EventID desc

PTable 大约有 5 亿行；EventID是ASC数据类型为 bigint（身份列）的主聚集索引列（ordered ）。顶部有多个线程向表中插入数据（较大的 EventID），底部有 1 个线程删除数据（较小的 EventID）。

在 SMSS 中，我们验证了两个查询始终使用相同的执行计划：

• 聚集索引扫描；

• 估计行数和实际行数均为1；

• 估计和实际执行次数均为1；

• 估计I/O成本是8500（好像有点高）

• 如果连续运行，则两者的查询成本相同 50%。

我更新了索引统计with fullscan，问题依旧；我再次重建索引，问题似乎消失了半天，但又回来了。

我打开了 IO 统计：

set statistics io on …