从 SELECT 拿到结果集很简单，难的是“怎么控制拿多少”。我见过太多人刚写完一条 SQL 就往程序里塞，结果测试环境数据量小没事，一到生产环境，一条查询把几十万行全捞回来，页面直接卡死。限制结果集这件事，说穿了就是四个需求：取前几条、分页、跳过前面若干条、每组取几条。SQL Server 里对应的手段也清清楚楚：TOP、OFFSET-FETCH、SET ROWCOUNT，再加上窗口函数。这一章就把这些东西全部捋一遍，讲清楚每个方案适合什么场景、有什么坑、为什么这么写。
1. 先从最常用的 TOP 说起：它不是“取几条”，是“排序后截断”
1.1 TOP 的三种基本写法
TOP 是 SQL Server 里最经典的限制结果集方式，语法上支持三种形式：
-- 固定行数 SELECT TOP 10 订单ID, 金额 FROM 订单; -- 固定百分比 SELECT TOP 10 PERCENT 订单ID, 金额 FROM 订单; -- 带变量 DECLARE @n INT = 20; SELECT TOP (@n) 订单ID, 金额 FROM 订单 ORDER BY 金额 DESC;固定行数最常用，百分比适合在报表里按比例抽样，带变量的写法常用于存储过程里动态控制返回行数。第三种的变量必须用括号包起来，直接写TOP @n会报语法错误，这是很多从 T-SQL 入门的人第一次踩到的地方。
1.2 有 ORDER BY 和无 ORDER BY，逻辑完全不同
很多人误以为TOP 10就是“取前 10 条”，但实际上如果没有ORDER BY，SQL Server 返回的是物理存储顺序上最先被扫描到的 10 条。这个顺序不保证、不稳定，甚至在同一条 SQL 反复执行时都可能变化，因为表扫描和索引扫描的行顺序受并行度、锁、内存压力影响。
-- 不加 ORDER BY：到底返回哪 10 条？没有人能保证 SELECT TOP 10 姓名, 分数 FROM 学生成绩; -- 加 ORDER BY：有了确定语义 SELECT TOP 10 姓名, 分数 FROM 学生成绩 ORDER BY 分数 DESC;这里有一个非常重要的执行顺序问题：SQL Server 是先排序，再截断 TOP。也就是说，TOP 10 ORDER BY 分数 DESC的逻辑等价于“按分数降序排完整个结果集，然后取前 10 行”。SQL Server 的执行计划会在 Sort 算子之后加上 Top 算子。数据量大时，Sort 可能溢出到 tempdb，这就是为什么TOP查询在大表上没有合适索引时会比想象中慢得多。
1.3 TOP PERCENT 的取整规则
TOP 10 PERCENT表示取总行数的百分之十，但有一个细节：如果计算结果不是整数，SQL Server 会向上取整。一张表有 99 行，TOP 10 PERCENT实际上会返回 10 行，而不是 9.9 行进位后的 9 行或四舍五入的 10 行。
-- 99 行的表，这条 SQL 会返回 10 行 SELECT TOP 10 PERCENT 列1 FROM 表;实际应用中，百分比这种写法更适合“抽样”场景，比如日志表里随机取一小批样本做分析。但要注意，抽样也必须有ORDER BY配合，否则取到的样本可能集中在存储的物理段首，代表性很差。抽样一般建议用TABLESAMPLE，它是更科学的随机抽样方式，TOP PERCENT 只是在特定业务下够用。
1.4 WITH TIES：把并列行一起带出来
TOP 还有一个比较少人知道的关键字：WITH TIES。它的含义是：在按 ORDER BY 排序后，如果第 N 行后面还有与第 N 行排序键相同的行，也一并返回。
-- 返回分数最高的若干人，分数相同的人不会被漏掉 SELECT TOP 3 姓名, 分数 FROM 学生成绩 ORDER BY 分数 DESC WITH TIES;假设前三名的分数是 98、97、97，这条 SQL 会返回 4 行，因为第 2、3 名分数一样，第 4 个也是 97 分，会作为并列行一起带出。这个功能在一些排行榜、评优场景里很实用，避免出现“同样分数但有人上榜有人落榜”的情况。不过要注意，WITH TIES只在有ORDER BY时才有效，否则没有“并列”的概念。
2. OFFSET-FETCH：分页这件事终于有了标准语法
2.1 基本语法与分页公式
SQL Server 2012 引入了OFFSET ... FETCH ...，这可以看作是 ANSI 标准的实现，也是目前最干净的分页写法。
-- 跳过前 20 行，取接下来的 10 行 SELECT 订单ID, 客户, 金额 FROM 订单 ORDER BY 订单ID OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;分页时的通用公式：
-- 第 pageNum 页，每页 pageSize 行 DECLARE @pageNum INT = 3; DECLARE @pageSize INT = 10; SELECT 列... FROM 表 ORDER BY 排序列 OFFSET (@pageNum - 1) * @pageSize ROWS FETCH NEXT @pageSize ROWS ONLY;OFFSET 可以单独使用，表示“跳过前面多少行、一直取到结尾”，但 FETCH 则必须配合 OFFSET 才能用。语法上FETCH NEXT n ROWS ONLY里的ONLY也可以省略成FETCH NEXT n ROWS，不过建议保留ONLY，语义更明确。
2.2 为什么说 OFFSET-FETCH 比 ROW_NUMBER 更直接
在 SQL Server 2012 之前，做分页的常规做法是用ROW_NUMBER()包一层子查询：
WITH CTE AS ( SELECT 订单ID, 客户, 金额, ROW_NUMBER() OVER (ORDER BY 订单ID) AS rn FROM 订单 ) SELECT 订单ID, 客户, 金额 FROM CTE WHERE rn BETWEEN 21 AND 30 ORDER BY 订单ID;这种写法性能上并不差，但可读性明显不如 OFFSET-FETCH，而且多了窗口函数计算的额外开销。OFFSET-FETCH 的意义不只在于省了几行代码，而是把“跳过多少行、取多少行”直接表达成查询意图，优化器理解起来更直接，执行计划也更清晰。
2.3 OFFSET-FETCH 与 TOP 的行为差异
有一件事很多人不知道：OFFSET-FETCH 在 SQL Server 里是借助 TOP 实现的。可以从执行计划里看到，SSMS 会在底层把 OFFSET 翻译成 TOP (Offset + Rows)，然后通过移除方式达到跳过目的。所以它继承了 TOP 的两个特性：
- 必须配合 ORDER BY 使用
- 排序之后才进行行数的截断和跳过
和 TOP 不同的是，OFFSET-FETCH 在跳过大量行时依然要扫描这些行，不会因为你“不看”就省掉读取成本。
-- 第 100 页，每页 10 行 -- 实际会扫描前 1000 行，然后丢弃前 990 行，最后返回 10 行 SELECT 订单ID FROM 订单 ORDER BY 订单ID OFFSET 990 ROWS FETCH NEXT 10 ROWS ONLY;这个特性在后面讲分页优化时会重点展开。
3. 每组取前 N 行：TOP 和窗口函数的组合玩法
3.1 ROW_NUMBER、RANK、DENSE_RANK 到底该怎么选
“每个部门工资最高的 3 个人”“每个分类销量前 5 的商品”，这种需求单靠 TOP 做不了，因为 TOP 是针对整个结果集的。这时候需要窗口函数先把组内序号算出来，再在外面过滤。
三个函数的核心差异在于并列排名的处理方式：
| 函数 | 相同排序值的处理 | 举例（分数 100, 100, 99, 98） |
|---|---|---|
| ROW_NUMBER | 强制分配唯一序号 | 1, 2, 3, 4 |
| RANK | 相同值并列，但后续序号跳跃 | 1, 1, 3, 4 |
| DENSE_RANK | 相同值并列，后续序号连续 | 1, 1, 2, 3 |
业务上“取前 3 名”如果允许并列，用 DENSE_RANK 或 RANK，视乎是否需要保留名次间隔；如果只是技术上取 3 行，用 ROW_NUMBER 最直接。
3.2 经典的“每组 Top N”写法
-- 每个部门工资最高的 3 名员工 WITH Ranked AS ( SELECT 员工ID, 姓名, 部门ID, 工资, ROW_NUMBER() OVER (PARTITION BY 部门ID ORDER BY 工资 DESC) AS rn FROM 员工 ) SELECT 员工ID, 姓名, 部门ID, 工资 FROM Ranked WHERE rn <= 3 ORDER BY 部门ID, 工资 DESC;这里需要注意几点：
第一，PARTITION BY 部门ID决定分组边界，ORDER BY 工资 DESC决定组内排序。两者缺一不可，顺序也别搞反。
第二，外层过滤rn <= 3不能直接写到窗口函数的 WHERE 里。窗口函数的计算发生在 WHERE 过滤之后，如果想在拿到组内序号前先过滤某些行，要分两层处理：先 WHERE 过滤，再计算行号。
第三，这种写法在大表上性能取决于索引是否能支撑PARTITION BY和ORDER BY的计算。比如上面这个 SQL，索引(部门ID, 工资 DESC)可以大幅降低 Sort 开销。如果没有合适索引，SQL Server 会把整个员工表先排序，代价很高。
3.3 TOP 也能实现每组取 N，但写法丑
其实不用窗口函数也能做“每组取五条”，就是自连接计数：
SELECT e1.部门ID, e1.员工ID, e1.工资 FROM 员工 e1 WHERE ( SELECT COUNT(*) FROM 员工 e2 WHERE e2.部门ID = e1.部门ID AND e2.工资 > e1.工资 ) < 3;这个写法在数据量小的时候没问题，但本质是嵌套子查询方式，复杂度高、性能差，而且并列处理逻辑很容易写错。我更推荐用窗口函数，它不仅语义清晰，执行计划优化空间也更大。
4. SET ROWCOUNT：一个不建议再用的“全局开关”
4.1 SET ROWCOUNT 的作用范围比想象中大
SET ROWCOUNT是一个会话级别的设置，会让 SQL Server 停止处理，在返回指定行数后立即停止查询处理。
SET ROWCOUNT 100; SELECT 订单ID, 客户 FROM 订单 ORDER BY 订单ID; SET ROWCOUNT 0; -- 恢复默认很多人以为它只是限制“结果集行数”，但实际上，它也会影响 UPDATE 和 DELETE。这是它比 TOP 危险得多的原因。
SET ROWCOUNT 100; -- 危险：只更新 100 行，而不是所有满足条件的行 UPDATE 订单 SET 状态 = '已处理' WHERE 状态 = '待处理'; -- 危险：只删除 100 行 DELETE FROM 日志 WHERE 登记时间 < '2024-01-01'; SET ROWCOUNT 0;如果忘记把SET ROWCOUNT重置为 0，后面同一会话里所有 DML 都会被截断。这个全局性副作用让 SQL Server 官方也建议不要把它用在存储过程或函数里，而是改用TOP来实现单条语句的行数限制。SQL Server 2005 以后对 SET ROWCOUNT 的支持就停留在兼容层面，文档里明确标注了“后续版本可能不再支持”。
4.2 SET ROWCOUNT 与动态 TOP 的场景
SET ROWCOUNT也有一些比较古老的用法，比如在动态 SQL 里避免拼接TOP (@n)这种语法。但在现代 SQL Server 版本中，TOP 本身已经支持变量，这种方法完全没必要再用。
-- 现代写法：TOP 直接接变量 DECLARE @n INT = 50; SELECT TOP (@n) 订单ID FROM 订单 ORDER BY 订单ID;4.3 SET ROWCOUNT 与查询提示的冲突
如果一条查询同时有SET ROWCOUNT n和 TOP 或 OFFSET-FETCH，SQL Server 会取更严格的那个限制。这个行为很容易让排查问题的人摸不着头脑：明明 SQL 写了TOP 100，为什么只返回 30 行？因为会话里有一个残留的SET ROWCOUNT 30。排查这种问题时要先检查连接会话级别设置。
5. 结果集限制背后的性能真相：TOP 不等于快
5.1 TOP 在两种情况下效率完全不同
这是一个被误解很深的地方：TOP 的性能取决于 ORDER BY 的排序列上有没有索引。
如果 ORDER BY 列有索引，SQL Server 可以按索引顺序扫描，读到前 N 行就停止，实际读取的页面很少，性能非常高。如果排序列没有索引，SQL Server 必须先完成一次完整排序（Sort 算子），才能截断 TOP 的行数，这种情况下 TOP 带来的节省很小，你依然要付出全表扫描和排序的代价。
-- 订单表：订单ID 有聚集索引，金额没有索引 -- 场景一：按订单ID 取前 100 条 —— 很快，索引顺序扫描前几页就能拿到 SELECT TOP 100 * FROM 订单 ORDER BY 订单ID; -- 场景二：按金额取前 100 条 —— 慢，需要全表扫描 + 全量排序 SELECT TOP 100 * FROM 订单 ORDER BY 金额 DESC;所以在建表索引时，要针对“最需要 TOP / 分页的排序键”设计索引。最常见的分页查询ORDER BY 主键能走聚集索引扫描，前几页性能没问题，但翻到很深的页时依然会遇到深分页问题。
5.2 深分页为什么慢，以及改 keyset 分页
深分页是指 OFFSET 数量很大的情况，比如第 10000 页。OFFSET-FETCH 必须先扫描并丢弃前 100000 行，然后才返回后面的 10 行，越翻越慢。
-- 深分页：第 10000 页 SELECT 订单ID, 客户 FROM 订单 ORDER BY 订单ID OFFSET 100000 ROWS FETCH NEXT 10 ROWS ONLY;优化思路之一是用 keyset 分页，也就是记住上一页最后一条记录的主键，下一页直接从它后面取：
-- 第一页 SELECT TOP 10 订单ID, 客户 FROM 订单 ORDER BY 订单ID; -- 第二页（把上一页最后一条的订单ID 传入，比如 100010） SELECT TOP 10 订单ID, 客户 FROM 订单 WHERE 订单ID > 100010 ORDER BY 订单ID;这样每一页都走索引 seek，和总页数无关，性能非常稳定。缺点是无法直接跳到指定页，适合“下一页/上一页”的交互模式，不适合“点击第 N 页”的传统分页器。
5.3 优化器对 TOP 的启发式干扰
TOP 的存在会改变整个查询的成本估算，SQL Server 的优化器认为只需要返回少量行，可能选择嵌套循环连接而不是哈希连接。这个启发式考虑在大多数场景是合理的，但偶尔会遇到统计信息严重过时、TOP 值极小、却人为导致错误执行计划的情况。实际排查时，如果发现同一查询去掉 TOP 反而更快，可以检查统计信息是否最新，或者考虑查询提示（如HASH JOIN）。但查询提示是最后手段，优先更新统计信息。
6. 限制结果集跨数据库实现差异
6.1 MySQL 的 LIMIT 语法和 SQL Server 的差异
MySQL 用LIMIT做限制，语法非常直接：
-- 取前 10 条 SELECT * FROM orders ORDER BY order_id LIMIT 10; -- 分页：跳过 20 条，取 10 条 SELECT * FROM orders ORDER BY order_id LIMIT 20, 10; -- 等价写法 SELECT * FROM orders ORDER BY order_id LIMIT 10 OFFSET 20;和 SQL Server 不同，MySQL 的 LIMIT 在绝大多数情况下不强制 ORDER BY，但不加 ORDER BY 的结果同样不稳定。另一个大区别是 MySQL 的LIMIT直接支持“偏移量+行数”两个参数，而 SQL Server 必须写 OFFSET、FETCH 两个关键字。
6.2 Oracle 12c 前后：ROWNUM 与 FETCH FIRST
在 Oracle 12c 之前，限制结果集要借助ROWNUM：
SELECT * FROM ( SELECT 订单ID, 客户 FROM 订单 ORDER BY 订单ID ) WHERE ROWNUM <= 10;ROWNUM 是在结果集产生后、排序之前分配的，所以必须先排序再限制。Oracle 12c 之后引入了标准语法：
SELECT 订单ID, 客户 FROM 订单 ORDER BY 订单ID FETCH FIRST 10 ROWS ONLY;这和 SQL Server 的 OFFSET-FETCH 思路完全一致，只是把FETCH NEXT换成了FETCH FIRST，语义上没有差别。
6.3 PostgreSQL 的 LIMIT / OFFSET 兼容性
PostgreSQL 同样使用 LIMIT 和 OFFSET：
SELECT * FROM 订单 ORDER BY 订单ID LIMIT 10 OFFSET 20;而且 PostgreSQL 也实现了 SQL 标准的 OFFSET-FETCH：
SELECT * FROM 订单 ORDER BY 订单ID OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;在限制结果集这个能力上，SQL Server、Oracle、PostgreSQL 三个主流数据库基本没差别，只有 MySQL 还没走标准语法这一道路。跨数据库迁移时，除了语法替换，还要注意事务隔离级别和排序列的唯一性，这些会影响结果的可复现性。
6.4 排序列不唯一时的风险
这是一个容易踩的共性坑。无论哪个数据库，只要分页的排序列不是唯一键，翻页时就可能遇到数据重复或遗漏。因为相同排序值的行在两次查询之间的返回顺序不固定。
解决办法是在 ORDER BY 末尾追加唯一键：
-- 错误示范：分数可能有大量重复 SELECT 订单ID, 分数 FROM 学生成绩 ORDER BY 分数 DESC OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY; -- 正确做法：追加唯一列，确保次序稳定 SELECT 订单ID, 分数 FROM 学生成绩 ORDER BY 分数 DESC, 订单ID ASC OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY;这个细节在数据量小的时候没什么感觉，一旦数据量上来、有人在同一时间并发点下一页，就会出现页码错乱的诡异 bug。追查起来还不容易，因为不是每次必现。
7. 实操中的几个经验建议
限制结果集看似简单，但实际项目和面试题里最容易出问题的就是在组合场景中把各种手段搞混。
第一个建议：能用 TOP 或 OFFSET-FETCH 就不要用 SET ROWCOUNT。TOP 是语句级的，SET ROWCOUNT 是会话级的，作用范围完全不同。维护旧项目时看到 SET ROWCOUNT 一定要检查后面有没有对应的 SET ROWCOUNT 0，不然就是一个定时炸弹。
第二个建议：分页查询一定要给 ORDER BY 追加唯一列。没有唯一键保证顺序，OFFSET-FETCH 在数据变化时可能让你看到重复或缺失的数据。这个习惯一旦养成，能避开大量微妙的问题。
第三个建议：不要对大表写深分页。如果产品要求任意跳页，把前面的页码处理成“最多可翻 200 页”或者用缓存存前几页的结果；如果是无限滚动分页，直接用 keyset 方案，也就是记住上一页最后一条的排序列值。
第四个建议：遇到 TOP 查询慢，第一时间不是加查询提示，而是看执行计划里 Sort 算子有没有走索引。TOP 配合合适的索引是行数级读取，性能是惊人的，很多场景慢的根源不在 TOP 本身，而在排序条件无法利用索引。
第五个建议：TOP 10 PERCENT慎用。百分比取数是向上取整的，而且如果配合 ORDER BY 时数据分布不均匀，取出来的样本代表性未必好。做抽样分析优先考虑 TABLESAMPLE。
最后分享一个我常用的排查方法：当分页结果异常时，把查询里的 OFFSET-FETCH 或 TOP 去掉，先用 COUNT 确认总行数和数据分布，再用DBCC SHOW_STATISTICS查看排序列的分布情况。限制结果集本身是简单的语法，真正的挑战永远在于排序、索引和数据分布之间的配合。能把这一层想透，不管是 TOP、OFFSET-FETCH 还是窗口函数，用起来都会比别人稳得多。
