莱夢分页查询报慢这种问题，大家第一反应都是“数据量太大了”。但“Sql Server使用row_number over方式分页，数据量五千多条就慢到20多秒”这个具体场景，我印象特别深——因为当年我接到类似报障时，第一反应也是查数据量，结果被现实狠狠教育了一课。五千多条记录，对Sql Server来说连“零头”都算不上，这种量级如果还需要20多秒，问题几乎可以肯定不在“数据多”，而在“查询是怎么被执行的”。
这篇我打算把整个排查链路和解决方案完整拆开聊。包括row_number over分页到底慢在哪、为什么数据量“不大”也会慢、我用什么手段定位根因、最终用哪种索引或改写方案解决，以及替换方案时容易忽略的坑。如果你也正在被Sql Server分页慢查询折磨，这篇应该能帮你省下不少排查时间。
1. row_number over分页的执行机制，以及那个“看起来不该慢”的瓶颈
在动手改任何东西之前，先把问题本身的机制吃透。Sql Server里ROW_NUMBER() OVER (ORDER BY ...)实现分页，逻辑上很直观：
sql复制;WITH PageData AS
(
SELECT
col1, col2,
ROW_NUMBER() OVER (ORDER BY CreateTime DESC) AS RowNum
FROM MyTable
)
SELECT * FROM PageData
WHERE RowNum BETWEEN 5000 AND 5030
这段SQL的逻辑分三步：全表取数、按排序字段编号、取编号区间。听着很“标准”，但执行起来完全不是这么回事。我的经验是，只要遇到分页性能问题，第一步去翻实际执行计划，十次里有八次能看到一个吓人的Sort操作符。这个Sort往往占据整个执行计划成本的80%以上。
为什么排序这么慢？你可以把ROW_NUMBER() OVER (ORDER BY CreateTime DESC)理解为：数据库得先把满足条件的所有行都找出来，再按CreateTime做一次完整的排序，之后才能给你编行号。问题就出在这个“先排序、后分页”模型上——你要的是第5001到第5030行，但数据库为了确定这30行是“第5001行”，必须先把前5000行也排好序。
有一种生活化的类比：你去图书馆找一本书。正确做法是管理员按分类号直接定位到对应书架。但你现在的分页写法等于要求管理员“把整个图书馆的书按出版日期全部重排一遍，然后告诉你第5001本是什么”——哪怕你只看第5001页，他也必须把前面5000本的位置都确定下来。
五千多条记录理论上排序很快，几毫秒到几十毫秒的事。那为什么实际要20多秒？因为实际执行计划里往往不止一个Sort，还可能存在大量Key Lookup。Key Lookup相当于：数据库已经通过非聚集索引找到了符合条件的行的“指针”，但你要的列不在这张索引里，它还得拿着指针回原表一行一行取数据。行数少的时候无所谓，但如果每一行都要这样“回表”，再加上排序操作产生的临时数据 spill 到磁盘，性能会断崖式下降。
基于以上机制，我得先纠正好几个常见认知误区，不然排查方向很容易跑偏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三个容易走偏的排查误区：先别急着怪“数据量”，也别急着换写法
很多人遇到分页慢，第一反应是“是不是row_number写法不行”。我接过很多这类案例，发现前几个排查方向其实都不太对，先帮你排掉。
2.1 误判一：五千条就慢，所以分页不该用row_number
这个结论下得太早了。Row_number本身不是瓶颈，瓶颈是它背后的排序没有可用索引支撑，或者排序字段的统计信息严重过期，导致优化器选错了执行计划。
我举个实际案例。当时排查一个生产库问题，某业务表确实只有五千多条，按CreateTime倒序分页，页数越深越慢，到第100页的时候单次查询跑了18秒。执行计划里出现了两个排序操作，而且CreateTime列上的索引因为长期没有更新统计信息，优化器估算的行数比实际差了将近30倍。基于错误估算，它选择了一个“先全表扫描再排序”的计划。后来只更新了一下统计信息，再配合类型匹配的索引，同样的查询耗时从18秒降到了180毫秒。
所以我的建议是：不要急着否定row_number方案，先排查是不是排序索引缺失、统计信息过期、隐式类型转换导致索引失效。这些才是大头。
2.2 误判二：加个“万能索引”就行，索引列随便选
索引设计最常见的错误就是“在排序字段上随便加个单列索引”。ORDER BY CreateTime DESC确实需要CreateTime上的索引，但你还要考虑查询结果要返回哪些列。
如果只建`CREATE INDEX IX_Table_Cre