1
从索引列上非常大的表中选择SELECT TOP 1非常慢，但不是相反的顺序（“ desc”）
我们有一个大型数据库，大约1TB，在功能强大的服务器上运行SQL Server 2014。几年一切正常。大约2周前，我们进行了全面维护，其中包括：安装所有软件更新；重建所有索引和紧凑的数据库文件。但是，我们没想到在实际负载相同的情况下，在某些阶段数据库的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（标识列）的主聚集索引列（有序）。有多个线程在顶部的数据表中插入数据（较大的EventID），有1个线程从底部的数据表中删除数据（较小的EventID）。 在SMSS中，我们验证了两个查询始终使用相同的执行计划： 聚集索引扫描； 估计行数和实际行数均为1； 估计的执行次数和实际的执行次数均为1； 估计I / O成本为8500（似乎很高） 如果连续运行，则两者的查询成本都是相同的50％。 我更新了索引统计信息with fullscan，问题仍然存在；我再次重建了索引，问题似乎消失了半天，但又回来了。 我通过以下方式打开了IO统计信息： set statistics io on 然后连续运行两个查询，发现以下信息： （对于第一个查询，慢速查询） 表“ PTable”。扫描计数1，逻辑读407670，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。 （对于第二个查询，快速查询） …