窗口函数是SQL中处理排名、分组统计类需求的利器，而分页几乎是所有列表页面的标配需求。把两者放在一起使用时，不少人会疑惑：LIMIT到底是在窗口函数计算之前生效，还是之后生效？为什么有时候加了LIMIT之后排名结果变得不完整？这篇文章就从SQL的执行顺序讲起，把窗口函数与LIMIT的配合逻辑彻底讲清楚，并给出几种可靠的分页实现方案。
先搞清楚：SQL的逻辑执行顺序决定了LIMIT的行为
要理解窗口函数和LIMIT的关系，必须先明白SQL语句的逻辑处理顺序。一条完整的SELECT语句，虽然书写顺序是FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY、LIMIT，但数据库实际执行的逻辑顺序却不是这样。WHERE会最先过滤数据，然后经过GROUP BY和HAVING完成分组过滤，接着才进入SELECT阶段计算表达式，而窗口函数恰恰是在SELECT阶段、ORDER BY之前完成计算的，LIMIT则排在所有步骤的最后。
这个顺序意味着两件事：第一，WHERE条件无法直接使用窗口函数的计算结果，因为WHERE执行时窗口函数还没算出来；第二，LIMIT只是对最终结果集做截断，它不会影响窗口函数已经计算出的值。举个例子，假设有一张员工表，我们按薪资从高到低用ROW_NUMBER()编号，再对整个查询加LIMIT 5，此时窗口函数会先对全表数据完成编号，然后LIMIT只取前5行返回。看起来结果没问题，但问题隐藏在分页场景中。
SELECT
emp_name,
salary,
ROW_NUMBER() OVER (ORDER BY salary DESC) AS rn
FROM employees
ORDER BY salary DESC
LIMIT 5;
上面的写法在取第一页时是正确的。但如果直接改成LIMIT 5 OFFSET 5去取第二页，依然能得到正确结果，前提是排序字段没有重复值。一旦排序字段存在相同值，不同批次查询的排序可能不稳定，分页结果就可能出现重复或遗漏。这就是窗口函数分页中第一个需要警惕的坑：排序不唯一导致分页错乱。
用ROW_NUMBER做分页：比OFFSET更可控的方案
ROW_NUMBER是最适合做分页的窗口函数，它的核心思路是：先给每一行分配一个从1开始的连续编号，再对这个编号做范围过滤。这样分页逻辑不再依赖物理偏移量，而是基于一个确定的逻辑列，结果可复现、可验证。标准写法是把窗口函数放在子查询或CTE中，外层再过滤编号区间。
WITH ranked AS (
SELECT
emp_name,
department,
salary,
ROW_NUMBER() OVER (ORDER BY salary DESC, emp_id) AS rn
FROM employees
)
SELECT emp_name, department, salary
FROM ranked
WHERE rn BETWEEN 6 AND 10; -- 第2页，每页5条
注意排序键中加入了emp_id作为兜底字段，保证排序完全确定。这一点非常重要，如果只按salary排序，两条薪资相同的记录在不同查询中顺序可能互换，导致某一页出现重复数据、另一页丢数据。这也是很多线上分页bug的根源。
这种写法相比OFFSET有一个明显优势：OFFSET的语义是丢弃前N行，数据量越大，翻到越靠后的页，数据库需要扫描和丢弃的行就越多，性能会线性劣化。而基于ROW_NUMBER的方案虽然也需要先计算编号，但结合合适的索引，数据库往往可以优化扫描范围。当然，ROW_NUMBER分页本质上仍要为前面的行编号，深度分页场景下更推荐键集分页（记住上一页最后一条记录的排序值，用WHERE条件直接定位），两者可以结合使用。
RANK和DENSE_RANK为什么不适合直接分页
同样是排名函数，RANK和DENSE_RANK在遇到并列值时会产生不连续的编号。RANK对并列值给出相同名次，并跳过后续名次，比如两个并列第2名之后，下一条直接是第4名；DENSE_RANK则不跳号，两个并列第2名之后是第3名。这种不连续性会让BETWEEN区间过滤出现行数不固定的页面，某一页可能只有3条，某一页可能有7条。
SELECT
emp_name,
salary,
RANK() OVER (ORDER BY salary DESC) AS rank_num,
DENSE_RANK() OVER (ORDER BY salary DESC) AS dense_num
FROM employees;
-- 假设前3名薪资为 30000, 25000, 25000
-- RANK结果为 1, 2, 2, 4...
-- DENSE_RANK结果为 1, 2, 2, 3...
但这不代表RANK系列函数在分页中毫无用处。在竞赛排名、排行榜这类需求中，业务上往往要求同一页内展示相同名次的所有记录，此时用RANK过滤反而更合理。另一种常见用法是先用ROW_NUMBER分页，同时在SELECT列表中附带RANK列用于展示名次，两个函数各司其职：ROW_NUMBER负责定位行，RANK负责展示语义上的名次。
不同数据库下的写法差异与性能建议
各数据库对分页语法的支持并不统一。MySQL和PostgreSQL使用LIMIT ... OFFSET ...，SQL Server早期版本没有LIMIT，需要用OFFSET ... FETCH（SQL Server 2012之后）或者TOP加ROW_NUMBER双层嵌套，Oracle则习惯用ROWNUM外层过滤。下面是SQL Server基于窗口函数的经典分页写法。
-- SQL Server 写法
SELECT emp_name, salary
FROM (
SELECT emp_name, salary,
ROW_NUMBER() OVER (ORDER BY salary DESC, emp_id) AS rn
FROM employees
) AS t
WHERE rn BETWEEN 6 AND 10
ORDER BY rn;
-- Oracle 12c 之后的简洁写法
SELECT emp_name, salary
FROM employees
ORDER BY salary DESC, emp_id
OFFSET 5 ROWS FETCH NEXT 5 ROWS ONLY;
性能层面有几点建议。首先，为排序键建立合适的复合索引，让窗口函数的排序能直接利用索引顺序，避免额外的排序操作。其次，分页编号的起始值要和页码计算严格对应，第page页、每页size条对应的区间是(page-1)*size+1到page*size，这个边界很容易算错，建议封装成统一的查询构造逻辑。最后，对于可以无限滚动的场景，考虑改用键集分页，用WHERE (salary, emp_id) < (上次最后一条的值)这类元组比较直接定位下一批数据，性能比任何编号方案都稳定。
总结一下核心要点：LIMIT在窗口函数计算之后执行，只截断行，不影响已算出的函数值；做分页首选ROW_NUMBER并保证排序键唯一；RANK和DENSE_RANK适合展示名次而非定位分页；配合索引和键集分页思想，才能让深分页场景保持良好性能。掌握这些规则，窗口函数与分页的组合使用就不再有歧义了。