第一次从MySQL迁到SQL Server，我差点以为装了个假数据库。SELECT ... LIMIT 10在MySQL里跑得行云流水，到SQL Server控制台一敲，直接给我一句Incorrect syntax near 'LIMIT'。查了半天文档才反应过来，SQL Server压根没有把LIMIT当作保留关键字，想实现同样的“限制返回行数”和分页效果，得用TOP、ROW_NUMBER()或者2012版以后才提供的OFFSET ... FETCH。
这篇文章就把这三种写法的思路、语法、常见坑和性能问题一起说透，适合正在从MySQL/Oracle往SQL Server迁移、或者被要求把老系统一堆分页SQL改造成标准写法的开发、运维、数据分析同学。全文不绕弯子，直接上干货。
1. 为什么SQL Server里没有“原生”LIMIT：取数哲学的差异
1.1 LIMIT是MySQL的扩展方言，不是SQL标准的一部分
先纠正一个常见误解：LIMIT并不是SQL标准里规定的东西，它最早来自MySQL，属于对标准SQL的扩展。标准SQL的核心操作对象是“集合”，一个查询结果就是一个集合或多集，在集合模型里所有行地位平等，逻辑上并不存在“第几行”这种物理位置概念。SQL Server从设计上更贴近标准模型，所以它一直没有提供LIMIT，而是用TOP表达“取前N行”，再从2012版本开始支持OFFSET/FETCH，这部分属于SQL:2008标准引入的语法。
不要小看这个理念差异。很多人从MySQL切到SQL Server，第一反应是“SQL Server太落后了”，其实两边只是思路不同。MySQL的LIMIT非常直接，就像从一叠纸里抽第3张到第7张；SQL Server则希望你先把这叠纸按明确规则排好，再告诉它你要哪一段。OFFSET/FETCH就是后一种思路的产物。
这也解释了为什么Oracle早期用ROWNUM、DB2用FETCH FIRST、SQL Server用TOP，各写各的。只要理解了这个背景，再去看各种“方言”就不会觉得乱，反而能快速对应到自己的目标语法。
1.2 没有ORDER BY谈Limit，就是碰运气
不管用哪种写法，SQL Server里的“限制行数”本质上都依赖一个前提：查询结果有确定的顺序。关系表本身没有顺序，你插入数据时是第1条、第2条，不代表SELECT出来还是这个顺序。SQL Server并行执行时，同一个查询今天跑出来的“前10行”和昨天跑出来的“前10行”，可能是完全不同的数据。
MySQL允许你写SELECT * FROM Orders LIMIT 20而不带ORDER BY，这属于宽容，不是保证。SQL Server的OFFSET/FETCH则直接把ORDER BY作为前提，语法上强制要求先排序。我见过不少线上问题，最后都归结为一句话：分页SQL没写ORDER BY，或者ORDER BY字段不唯一，导致翻页乱跳、数据重复。所以后面所有示例都会先强调排序键，这真的不是洁癖，是保命。
2. TOP加ORDER BY：最直接的限制行数写法与三个常见陷阱
2.1 基础语法与两种常见形态
TOP是做“取前N行”最简洁的写法：
SELECT TOP (10) OrderID, OrderDate, CustomerID FROM dbo.Orders ORDER BY OrderDate DESC, OrderID DESC;括号不是必须的，TOP 10也能用，但一旦涉及变量或表达式，括号就必须加：
DECLARE @TopN INT = 20; SELECT TOP (@TopN) OrderID, OrderDate, CustomerID FROM dbo.Orders ORDER BY OrderDate DESC;还有个容易被忽略的TOP (10) PERCENT形态，它会按结果集总行数的一定比例返回记录。如果总行数是25行，取10%会返回3行，因为SQL Server对百分比计算结果是向上取整的。这个细节在报表抽样场景里非常容易踩，建议先确认业务到底想要精确条数，还是想要一个大概比例。
补充一个冷门但实用的点：UPDATE TOP (5) ...和DELETE TOP (5) ...也是合法的，但UPDATE/DELETE的TOP不支持ORDER BY，也就是说被更新的5行到底是谁，完全取决于执行计划选出来的物理顺序，风险极高。凡是带副作用的操作，尽量不要依赖TOP的隐式顺序。
2.2 陷阱一：不写ORDER BY时，TOP取谁完全不可预测
SELECT TOP (10) OrderID, OrderDate FROM dbo.Orders是不报错的，所以很多人顺手就写了。问题是：这10行是哪10行？在堆表里可能是物理存储顺序的前10行；如果走的是非聚集索引，可能是索引扫描路径上的前10行；一旦统计信息变化、执行计划变成并行、或者有人加了个新索引，结果可能完全不一样。
生产环境里这种“偶发性数据不一致”特别难排查，因为不是每次必现，往往大数据量下才冒出来。而且应用层通常还需要一个稳定的顺序去展示，所以我的习惯是：凡是TOP，一律配ORDER BY；凡是ORDER BY，排序键尽量加一个唯一字段兜底。这条规则能帮你躲掉后面一半的坑。
2.3 陷阱二：ORDER BY字段不唯一时，分页会重复或丢行
看这个例子：
SELECT TOP (10) OrderID, OrderDate FROM dbo.Orders ORDER BY OrderDate DESC;如果2025-05-01当天有500笔订单，而排序字段只有OrderDate一个，那么SQL Server在这500笔里选哪10笔，依然没有明确规则。第一页返回的可能包含OrderID=10000，第二页又可能出现OrderID=10000，因为同一天内所有行的排序键都相等，数据库没有依据区分它们。
解决办法是在ORDER BY里追加一个唯一键：
ORDER BY OrderDate DESC, OrderID DESC;这样每个行都有唯一的位置，分页才能稳定。这个问题MySQL分页同样存在，不是SQL Server独有，只是TOP语法让很多人误以为“取前N条”就不需要考虑顺序稳定性。
2.4 陷阱三：TOP本身做不了分页，只能取头部
TOP解决的是“取前N条”，解决不了“跳过M条再取N条”。有些同学会想当然地写SELECT TOP (30) ...，然后在应用层丢掉前20条。这种做法在小数据量下不是不能用，但至少有三个问题：第一，SQL Server仍然把30条全部排好并返回，前20条的网络传输和内存开销是纯浪费；第二，应用层一旦改了页大小或页码，SQL逻辑就要跟着改，维护成本高；第三，如果外层还套了分页控件，行为会变得非常别扭。
所以TOP更适合限制行数、取最大值、抽查样本这些场景，真正的分页需求还是得用ROW_NUMBER()或OFFSET-FETCH。
3. ROW_NUMBER()开窗分页：所有版本通用的稳定方案
3.1 通用写法：先编号，再按区间过滤
ROW_NUMBER() 从SQL Server 2005开始引入，2008、2008R2、2012一直到2022都能用，是兼容性最强的分页方案。核心思路是先用开窗函数给查询结果编一个连续的行号，再在外面用WHERE过滤行号范围：
WITH OrderedOrders AS ( SELECT OrderID, CustomerID, OrderDate, ROW_NUMBER() OVER (ORDER BY OrderDate DESC, OrderID DESC) AS RowNum FROM dbo.Orders ) SELECT OrderID, CustomerID, OrderDate FROM OrderedOrders WHERE RowNum BETWEEN 21 AND 40 ORDER BY OrderDate DESC, OrderID DESC;注意外层我最后又写了一次ORDER BY。有人会问：里面不是已经排好了吗？但逻辑上，WHERE过滤之后返回的仍然是一个集合，数据库不保证输出顺序一定按RowNum排列。为了展示给用户时不乱序，外层最好再显式排序。
3.2 分页公式：从第几行到第几行
假设页码@PageNo从1开始，页大小@PageSize为20，那么第N页的行号区间是：
- 起始行：
(@PageNo - 1) * @PageSize + 1 - 结束行：
@PageNo * @PageSize
比如第1页是1到20，第2页是21到40。对应到SQL里可以参数化：
DECLARE @PageNo INT = 2; DECLARE @PageSize INT = 20; DECLARE @StartRow INT = (@PageNo - 1) * @PageSize + 1; DECLARE @EndRow INT = @PageNo * @PageSize; WITH OrderedOrders AS ( SELECT OrderID, CustomerID, OrderDate, ROW_NUMBER() OVER (ORDER BY OrderDate DESC, OrderID DESC) AS RowNum FROM dbo.Orders ) SELECT OrderID, CustomerID, OrderDate FROM OrderedOrders WHERE RowNum BETWEEN @StartRow AND @EndRow ORDER BY OrderDate DESC, OrderID DESC;这里我建议先用变量把起始行、结束行算好，不要直接在BETWEEN里写一大串运算表达式。代码更清晰，也方便排查页数传错的问题。
3.3 大坑：先过滤再编号，还是先编号再过滤？
这是ROW_NUMBER分页里最容易翻车的点。正确的顺序是：先在子查询里把WHERE条件做完，再计算行号；绝不能先算行号，再在外层过滤。
错误示例：
SELECT OrderID, CustomerID, OrderDate FROM ( SELECT OrderID, CustomerID, OrderDate, ROW_NUMBER() OVER (ORDER BY OrderDate DESC, OrderID DESC) AS RowNum FROM dbo.Orders ) t WHERE t.Status = 1 AND t.RowNum BETWEEN 21 AND 40;这个SQL的问题在于，RowNum是对所有订单（包括Status=0的订单）连续编号的。外层再过滤Status=1时，行号就出现了空洞，排序后第21到40条“有效数据”会被错误地截断。正确写法是把Status = 1放进内层：
SELECT OrderID, CustomerID, OrderDate FROM ( SELECT OrderID, CustomerID, OrderDate, ROW_NUMBER() OVER (ORDER BY OrderDate DESC, OrderID DESC) AS RowNum FROM dbo.Orders WHERE Status = 1 ) t WHERE t.RowNum BETWEEN 21 AND 40;JOIN场景同理，先JOIN完、过滤完，再编号，才能保证分页的数据范围是业务真正想要的数据范围。
3.4 为什么说它是老版本环境下最稳的选择
如果你维护的系统还是SQL Server 2008R2或2012早期，OFFSET-FETCH用不了，TOP又做不了分页，ROW_NUMBER()几乎是唯一的通用解。它不需要临时表，不需要IDENTITY列，一条SQL就能完成“跳过前N行再取M行”的需求，而且执行计划通常也就是“排序 + 计算标量 + 过滤”，可控性很高。
相比临时表的写法：
SELECT IDENTITY(int,1,1) AS RowNum, OrderID, OrderDate INTO #Temp FROM dbo.Orders ORDER BY OrderDate DESC;临时表方案要写两段SQL，还要考虑会话隔离、临时表清理，性能也没有优势。ROW_NUMBER()一条语句搞定，明显更适合日常分页。
4. OFFSET-FETCH：2012之后的官方分页写法与避坑要点
4.1 上手语法：ORDER BY ... OFFSET ... FETCH
SQL Server 2012开始支持OFFSET-FETCH，这是目前官方推荐的通用分页写法。语法非常直白：
SELECT OrderID, CustomerID, OrderDate FROM dbo.Orders ORDER BY OrderDate DESC, OrderID DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;意思是：先按OrderDate DESC, OrderID DESC排序，跳过前面20行，然后取接下来10行。这里有两个容易忽略的规则：
FETCH不能单独使用，必须和OFFSET一起出现；只想跳过前N行而不限制返回条数时，可以只写OFFSET 20 ROWS。OFFSET ... FETCH不是独立子句，它本质上属于ORDER BY子句的一部分，所以前面必须有ORDER BY。
如果你要的是第一页数据，可以写OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY，也就是从第0行偏移开始取，语义上等价于TOP写法，但代码风格统一，方便在一个查询模板里通过参数切换页号。
4.2 参数化分页：变量可以直接用
实际开发中页号和页大小通常来自前端参数，OFFSET-FETCH支持变量参数化：
DECLARE @PageOffset INT = 20; DECLARE @PageSize INT = 10; SELECT OrderID, CustomerID, OrderDate FROM dbo.Orders ORDER BY OrderDate DESC, OrderID DESC OFFSET @PageOffset ROWS FETCH NEXT @PageSize ROWS ONLY;关于OFFSET @PageNo * @PageSize ROWS这种直接写表达式的做法，我的建议是：能用变量就先算好，别在OFFSET里堆算术。一是老版本对表达式的支持容易让人在升级、迁移时踩到意外差异；二是执行计划参数化的可读性会更好，出问题时也容易定位。用变量和用常量写法的执行计划差别不大，但代码维护体验差很多。
4.3 它和ROW_NUMBER()的性能差别，没有想象中大
很多人以为OFFSET-FETCH是官方推荐，性能就一定碾压ROW_NUMBER()。实际上在简单分页场景里，两者的执行计划高度相似：都是先按ORDER BY排序定位范围，再取对应区间的行。所以小数据量下你几乎感觉不到差别，谁更简洁用谁。
真正的性能分水岭在“深度分页”，也就是页号很大、OFFSET值很大的时候。OFFSET 1000000 ROWS 意味着数据库要把前面100万行都定位并跳过，这个动作无论如何都省不掉。相比之下ROW_NUMBER()也是先给所有结果编号再做过滤，同样要把前面的大量行算完。两者在深度分页上都不是银弹，后面我会专门讲Keyset分页，那才是绕过这个问题的正路。
4.4 如果环境还是2012之前，怎么平替OFFSET-FETCH
碰到2008R2这种老环境，最直接的办法就是退回ROW_NUMBER()写法。虽然有人用TOP+NOT IN+ 子查询模拟过“跳过前N行”的效果，但那种SQL可读性差，执行计划也容易出现意外，不到万不得已我不建议在生产环境使用。
还有一种思路是把排序后的前(N+M)条取出来，再在应用层丢弃前N条，这个在数据量小的内部系统里勉强能用，但根本不适合正式业务。如果你正在做数据库版本升级规划，建议把OFFSET-FETCH作为升级后的重点改造点，它确实让分页SQL简洁很多。
5. 深度分页为什么越来越慢，以及Keyset分页优化方案
5.1 三种写法在深度分页场景的表现
先给一张对比表，方便你做选型：
| 方案 | 适用版本 | 写法难度 | 适合场景 | 深度分页表现 |
|---|---|---|---|---|
| TOP | 所有版本 | 低 | 取前N条、抽查、报表头部 | 不涉及跳过，无深度问题 |
| ROW_NUMBER() | 2005以上 | 中 | 老版本通用分页 | 越往后越慢，因为要全量编号 |
| OFFSET-FETCH | 2012以上 | 低 | 新项目通用分页 | 越往后越慢，因为要跳过大量行 |
这个“越往后越慢”的问题，在大表上会非常明显。比如一张5000万行的订单表，用户翻到第10万页，OFFSET值就是200万，SQL Server必须沿着排序好的数据一个个数过去、丢弃掉，再返回目标10行。这个动作的代价和页号成正比，所以很多后台系统明明数据量不大，却会在翻到后面几页时突然超时。
5.2 Keyset分页：记住上一页最后一条，而不是告诉数据库跳过多少行
Keyset分页，也叫Seek分页，核心思路是：不告诉数据库“跳过N行”，而是告诉它“从上一页最后一条记录之后开始取”。就像你看书不是每次从第1页数到第200页，而是直接翻到书签位置继续往后。
假设列表按OrderDate DESC, OrderID DESC排序，上一页最后一条是OrderDate = '2025-05-01 10:00:00', OrderID = 10086，下一页的SQL写成：
DECLARE @LastOrderDate DATETIME2 = '2025-05-01 10:00:00'; DECLARE @LastOrderID INT = 10086; SELECT TOP (20) OrderID, OrderDate, CustomerID FROM dbo.Orders WHERE OrderDate < @LastOrderDate OR (OrderDate = @LastOrderDate AND OrderID < @LastOrderID) ORDER BY OrderDate DESC, OrderID DESC;这段SQL的要点在于：排序键为升序时，条件相应改成>和>；排序键有多个字段时，就用“小于主排序字段，或者等于主排序字段但小于次排序字段”这种方式逐层描述边界。每次翻页只需要在索引上做一次seek，直接定位到上一页的结束位置，再往后取20行。成本基本恒定，不会因为页号变大而变慢。
它唯一的代价是：用户不能随便跳页，只能一页一页往后翻；应用层必须把上一页最后一条记录的排序键传给后端。不过对绝大多数“上一页/下一页”类型的列表来说，这个代价完全可以接受。
5.3 配合索引设计，效果才真正落地
Keyset分页要跑得快，前提是WHERE和ORDER BY涉及的字段有合适的索引。针对上面那个订单查询，可以建一个这样的索引：
CREATE INDEX IX_Orders_OrderDate_ID ON dbo.Orders (OrderDate DESC, OrderID DESC) INCLUDE (CustomerID, OrderAmount);OrderDate和OrderID作为索引键，正好匹配ORDER BY的排序方向；INCLUDE里把需要展示的列加进去，查询时就不用回表，进一步减少IO。对OLTP场景来说，这个优化经常能把一次分页查询从几百毫秒降到几毫秒。
但索引不是越多越好。每个索引都会拖慢INSERT/UPDATE/DELETE的写入性能，所以只针对真正的热点查询建索引，而不是为了“万一”把所有组合都建一遍。判断标准很简单：看执行计划里有没有Index Seek，如果还是Index Scan + Sort，说明索引没匹配上排序顺序。
5.4 MySQL LIMIT到SQL Server的快速改写对照
最后给一张迁移对照表，这也是我从MySQL转SQL Server时最想要的东西：
| 业务需求 | MySQL写法 | SQL Server写法 |
|---|---|---|
| 取前10行 | SELECT ... LIMIT 10 | SELECT TOP (10) ... |
| 跳过5行取10行 | SELECT ... LIMIT 5, 10 | ROW_NUMBER()过滤，或OFFSET 5 ROWS FETCH NEXT 10 ROWS ONLY |
| 取10行但偏移5行 | SELECT ... LIMIT 10 OFFSET 5 | OFFSET 5 ROWS FETCH NEXT 10 ROWS ONLY |
| 按某字段排序取最大的一条 | ORDER BY id DESC LIMIT 1 | SELECT TOP (1) ... ORDER BY id DESC |
| 取总行数的5% | MySQL一般要算总数再拼LIMIT | SELECT TOP (5) PERCENT ... |
注意MySQL的LIMIT 5, 10和LIMIT 10 OFFSET 5含义完全一样，都是偏移5行取10行，只是参数顺序不同；SQL Server这边统一用OFFSET 5 ROWS FETCH NEXT 10 ROWS ONLY表达这个语义，不容易混淆。
5.5 我通常怎么选分页方案
分页方案没有绝对标准，我也不是每个场景都上Keyset。这里分享一个经验顺序，供你参考：
- 只是限制返回条数，比如取Top 3、取最大一条，用TOP，简单直接。
- 老系统还在2008R2，改造成本高，继续用ROW_NUMBER()，至少稳定。
- 新项目、版本支持2012以上，优先写OFFSET-FETCH，代码最简洁。
- 大表、深度翻页、有明确排序键的场景，直接用Keyset分页，别等出了性能事故再改。
- 不管用哪种，ORDER BY里一定加唯一键做次级排序，这个习惯能避免一大半分页乱序问题。
最后再提醒一个容易被忽略的点：写分页SQL时，尽量把WHERE过滤条件放内层、把行号计算放在过滤之后。这个顺序错了，即使你的语法完全正确，分页结果也是错的。早年我在一个千万级流水表上吃过这个亏，查了整整一个下午才发现行号先算导致数据漂移。希望你不用再踩一遍。
