企业官网建设流程全解析

对用过MySQL再切到SQL Server的人来说，最难受的语法之一就是LIMIT。MySQL里一句SELECT ... LIMIT 10就能拿到前十条，LIMIT 20, 10就能跳过二十条再拿十条，分页写起来跟喝水一样简单。到了SQL Server，这语法直接不支持，很多新手第一反应是去装个MySQL或者换个数据库，其实完全没必要。

SQL Server不是没有分页能力，只是它把路子拆成了好几个版本、好几套方案。从早期的TOP，到2005年加入的ROW_NUMBER()，再到2012年以后的OFFSET FETCH，每种写法都有对应的适用场景。这篇文章我不讲安装、不讲下载，就单纯把“SQL Server里怎么实现类似LIMIT的效果”这件事讲透，覆盖取前N条、跳过N条、通用分页三个需求，顺便把我这些年踩过的坑一起列出来。不管你是刚从MySQL转过来的，还是在老项目里维护祖传SQL，这篇都值得看完。

1. 先理清“Limit”在SQL Server里到底缺什么

1.1 MySQL用户切换到SQL Server的第一个不习惯

先还原一下最常见的场景：你有一张订单表，想看看最近创建的10条订单记录。MySQL里你会写：

SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;

干净利落，一条语句收工。到了SQL Server里，同样的需求你会下意识敲出LIMIT 10，结果编辑器直接给你画红线，报语法错误。这时候很多人会开始怀疑人生：SQL Server怎么连这个都没有？

其实不是没有，是“实现方式不一样”。MySQL把取前N条做成了独立的关键字，而SQL Server把这件事拆成了两派思路：一派是显式取顶部的TOP，另一派是基于行号的排名函数ROW_NUMBER()，2012年之后又多了一个OFFSET FETCH语法。三种方案各有各的脾气，也各有各的局限。理解它们之间的关系，才是真正掌握SQL Server分页的关键，而不是死记一个写法。

1.2 把需求拆开看：三种不同的“Limit”场景

很多人一上来就搜“SQL Server LIMIT”，搜出来的答案五花八门，看着更晕。我的建议是先把需求拆清楚。所谓“类似LIMIT”，实际工作中无非就三种：

第一种是取前N条，比如排行榜前10、最新5条通知。这种最简单的做法就是TOP。

第二种是跳过前M条后取N条，比如跳过最近已读的20条通知，取后面的10条。这种需求在SQL Server 2012之前得靠ROW_NUMBER()，2012之后可以用OFFSET FETCH。

第三种是通用分页，也就是第page页、每页pageSize条，类似LIMIT (page-1)*pageSize, pageSize。这种是业务系统里最常见的分页写法，通常需要结合排序字段来保证结果稳定，ROW_NUMBER()和OFFSET FETCH都能做。

所以不要只盯着“有没有LIMIT”这一个问题，而是看你的具体场景。先把需求归类，再选对应方案，写起来就不会纠结。

2. TOP方案：最直接的前N条写法

2.1 TOP的基础语法和几个容易被忽略的变体

TOP是SQL Server里历史最悠久、最直观的取数语法。它的基础写法是这样的：

SELECT TOP 10 * FROM orders ORDER BY created_at DESC;

这条语句等价于MySQL的LIMIT 10。TOP可以接数字，也可以接变量：

DECLARE @n INT = 10; SELECT TOP (@n) * FROM orders ORDER BY created_at DESC;

注意变量写法必须加括号，不加括号会报错。还有两个变体经常被忽略：一个是TOP n PERCENT，按百分比取数；另一个是WITH TIES，用于把排序值相同的数据一并取出来。

TOP n PERCENT的用法是取前百分之多少的记录，比如取前1%的订单：

SELECT TOP 1 PERCENT * FROM orders ORDER BY created_at DESC;

这个在统计报表里偶尔会用，平时用得少。WITH TIES则解决了一个很实际的问题：你按某个分数排序取前10条，但第10名和第11名分数一样，TOP 10只会随机返回其中一个，加了WITH TIES会把所有分数等于第10名的记录全部带出来：

SELECT TOP 10 WITH TIES * FROM students ORDER BY score DESC;

这个特性在排行榜场景非常实用，MySQL的LIMIT反而没有这么方便。

2.2 TOP实现“跳过前N条”的别扭写法

TOP能做取前N条，但做不了“跳过前M条再取N条”。硬要用TOP实现，你也只能先查出前M+N条，再从结果里把前M条排除掉。常见写法是用子查询加NOT IN：

SELECT TOP 10 * FROM orders WHERE order_id NOT IN ( SELECT TOP 20 order_id FROM orders ORDER BY created_at DESC, order_id DESC ) ORDER BY created_at DESC, order_id DESC;

这个写法在数据量小的时候没问题，但只要orders表数据量大一点，子查询里的NOT IN就会让性能变得很难看。而且NOT IN遇到NULL还会出逻辑问题，虽然主键一般不会为NULL，但写成NOT EXISTS更稳：

SELECT TOP 10 * FROM orders o WHERE NOT EXISTS ( SELECT 1 FROM ( SELECT TOP 20 order_id FROM orders ORDER BY created_at DESC, order_id DESC ) t WHERE t.order_id = o.order_id ) ORDER BY created_at DESC, order_id DESC;

相信我，这种嵌套写一次就够够的了。更麻烦的是，当页码一变，子查询里的TOP 20又得跟着改，动态拼SQL的复杂度直线上升。所以我的结论很明确：用TOP来处理“跳过前N条”是实在没办法时的下策，能不用尽量别用。

2.3 TOP方案的真实性能与适用边界

从性能角度讲，TOP其实不差。因为SQL Server会在执行计划里把TOP当成一个“取够就停”的算子，配合合适的索引，找到N条记录后就不会再继续扫描了。MySQL的LIMIT也是一样的道理，所以在“取前N条”这个场景，TOP的效率非常高。

但它有个致命短板：没有“偏移量”的概念。你要的是第1000页的数据，它就没办法直接跳到第1000页，非得先把前999页的数据全部算出来再丢掉，代价极大。另外TOP配合ORDER BY时，如果排序字段上没有索引，SQL Server会先把全表数据排好序再取前N条，这种情况下就算只取1条，也可能把整张表都扫描一遍。

所以我的建议是：TOP只用来做“单纯取前N条”的需求，比如首页最新几条、排行榜前几条，别拿它去做分页核心。真要做分页，接着往下看。

3. ROW_NUMBER()窗口函数：老版本通用分页方案

3.1 为什么ROW_NUMBER能实现LIMIT offset, count

SQL Server 2005引入了窗口函数，其中ROW_NUMBER()就是用来给每一行生成行号的。它的核心作用相当于给结果集编个号，编完号之后，你想取第21到第30条，只需要筛选行号在21到30之间的记录就行。

这个逻辑跟LIMIT 20, 10的语义几乎完全对应：跳过前20条（行号1到20不要），取接下来的10条（行号21到30）。所以从2005到2012之间，ROW_NUMBER()就是SQL Server分页的标准答案，至今仍然大量运行在旧版本数据库和存量系统里。

先看最基础的写法：

SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM orders ) t WHERE rn > 20 AND rn <= 30;

这个WHERE rn > 20 AND rn <= 30就是偏移量的体现，20是跳过的条数，30是取数的终点。换成LIMIT 20, 10就是一模一样的效果。

3.2 分页查询完整SQL写法与排序陷阱

实际项目里分页肯定不能写死数字，得用变量或参数。假设当前页码是@page，每页条数是@pageSize，那SQL就是：

DECLARE @page INT = 3; DECLARE @pageSize INT = 10; DECLARE @startRow INT = (@page - 1) * @pageSize + 1; DECLARE @endRow INT = @page * @pageSize; SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC, order_id DESC) AS rn FROM orders ) t WHERE rn BETWEEN @startRow AND @endRow ORDER BY rn;

这里有一个特别容易踩的坑：ROW_NUMBER() OVER里的ORDER BY必须跟业务排序一致。如果你显示的时候想按创建时间倒序，那窗口函数里也必须是创建时间倒序，否则分页结果会“跳数据”或者“重复数据”，这个问题我后面在常见问题里还会细讲。

另一个坑是排序字段不唯一。假如你只按created_at排序，而同一秒内创建了100条订单，这100条记录的顺序在ROW_NUMBER()里是不确定的。两次查询可能得到不一样的行号分配，结果就是第一页和第二页之间出现重复或漏掉数据。解决方法是加一个唯一字段作为次级排序，比如主键order_id DESC，保证排序是完全确定的。

3.3 全套分页SQL示例：页码、每页条数动态传入

在存储过程里，完整的写法是这样：

CREATE PROCEDURE usp_GetOrdersByPage @page INT, @pageSize INT AS BEGIN SET NOCOUNT ON; DECLARE @startRow INT = (@page - 1) * @pageSize + 1; DECLARE @endRow INT = @page * @pageSize; SELECT * FROM ( SELECT order_id, customer_name, created_at, ROW_NUMBER() OVER (ORDER BY created_at DESC, order_id DESC) AS rn FROM orders ) t WHERE rn BETWEEN @startRow AND @endRow ORDER BY rn; END

调用的时候：

EXEC usp_GetOrdersByPage @page = 2, @pageSize = 20;

这个存储过程就是旧版本SQL Server最标准的分页方案。注意我把外层SELECT写成了具体字段而不是*，这是经验之谈：在窗口函数子查询里用*，如果哪天表加了text、ntext、image这类大字段，性能会迅速劣化，而且ORDER BY rn在外层也更容易看清楚输出顺序。

ROW_NUMBER()方案最大的优势是只要SQL Server 2005以上都能跑，兼容性极好。它最大的劣势是，对于大偏移量（比如跳到第10000页），它需要先把前10000页的所有行都编上号，再筛选出最后那页数据，CPU和内存开销都不小。

4. OFFSET FETCH：2012以后的原生“Limit”

4.1 语法对照：OFFSET ... ROWS FETCH NEXT ... ROWS ONLY

SQL Server 2012开始引入了OFFSET FETCH语法，这才是真正意义上和MySQLLIMIT对标的东西。它的基本写法是：

SELECT * FROM orders ORDER BY created_at DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;

对照一下MySQL的语法就非常清楚了：

-- MySQL SELECT * FROM orders ORDER BY created_at DESC LIMIT 20, 10; -- 等价于 SELECT * FROM orders ORDER BY created_at DESC LIMIT 10 OFFSET 20;

OFFSET 20 ROWS就是跳过20行，FETCH NEXT 10 ROWS ONLY就是取接下来的10行。把20和10换成变量，就是通用分页：

DECLARE @page INT = 3; DECLARE @pageSize INT = 10; DECLARE @offset INT = (@page - 1) * @pageSize; SELECT * FROM orders ORDER BY created_at DESC, order_id DESC OFFSET @offset ROWS FETCH NEXT @pageSize ROWS ONLY;

写起来比ROW_NUMBER()清爽太多了。而且从语义上，OFFSET就是“偏移量”，FETCH NEXT就是“取多少条”，一眼就能看懂这是在分页，后来接手你代码的人也会感激你。

4.2 OFFSET FETCH在使用上的几个硬性要求

OFFSET FETCH看起来简单，但有几个硬性规定不注意就会报错。

第一个硬性规定：必须配合ORDER BY使用。SQL Server的OFFSET FETCH不像MySQL的LIMIT可以裸写，如果你写了OFFSET却没有任何ORDER BY，会直接报错。逻辑上也说得通：不排序，数据库怎么知道要跳过哪些行？

第二个容易忽略的点：只写OFFSET不写FETCH是合法的。比如你要跳过前20条，然后取剩下所有记录，可以只写OFFSET 20 ROWS，后面不跟FETCH NEXT。这正好对应MySQL的LIMIT 20, 18446744073709551615那种写法。但大部分人不会这么用，还是建议统一写完整。

第三个点是关于OFFSET的具体数值。它支持变量和表达式，所以分页存储过程里可以很自然地传参，这比拼SQL字符串要安全得多。注意OFFSET后面不能省略ROWS关键字，FETCH NEXT的NEXT和ROWS ONLY也不能乱省。

4.3 与ROW_NUMBER的性能对比和选型建议

从性能角度看，OFFSET FETCH和ROW_NUMBER()在底层执行计划上其实相差不大，两者都需要扫描到偏移量对应的位置才能真正取值。但在写法体验和维护成本上，OFFSET FETCH完胜，前提是你的SQL Server版本在2012及以上。

我做过一次上百张表的分页改造，对比下来发现，同样的SQL逻辑，OFFSET FETCH的语句更短、可读性更高、参数化更自然。但有一个细节需要注意：OFFSET FETCH对执行计划的选择，在某些复杂查询里，不一定比ROW_NUMBER()优化得好。所以，如果你正在处理一个极其复杂的查询，最好两种写法都测试一下执行计划，不要迷信新语法。

版本选型上我是这么建议的：

• SQL Server 2012及以上：优先用OFFSET FETCH，代码最简、语义最清晰。
• SQL Server 2005到2008 R2：只能靠ROW_NUMBER()，这是标准答案。
• SQL Server 2000（还没升级的话）：只能用TOP加嵌套子查询硬凑，或者靠临时表，非常痛苦，建议尽快升级。

5. 通用分页存储过程的做法与我的取舍

5.1 一段可以直接抄的通用分页存储过程

既然聊到分页，必须说项目里最常见的封装方式：写一个通用分页存储过程，把表名、排序字段、页码、每页条数作为参数传进去，内部动态拼接SQL。我见过不少项目都是这么干的，前几年我自己也写过。这里先给一个比较保守的示例，适用于SQL Server 2008以上的环境，用ROW_NUMBER()方案：

CREATE PROCEDURE usp_PagedQuery @TableName NVARCHAR(200), @Columns NVARCHAR(1000) = '*', @WhereClause NVARCHAR(2000) = '', @OrderByClause NVARCHAR(500), @Page INT = 1, @PageSize INT = 20 AS BEGIN SET NOCOUNT ON; DECLARE @sql NVARCHAR(MAX); DECLARE @startRow INT = (@Page - 1) * @PageSize + 1; DECLARE @endRow INT = @Page * @PageSize; SET @sql = N' SELECT * FROM ( SELECT ' + @Columns + ', ROW_NUMBER() OVER (ORDER BY ' + @OrderByClause + ') AS rn FROM ' + @TableName + (CASE WHEN @WhereClause <> '' THEN ' WHERE ' + @WhereClause ELSE '' END) + ' ) t WHERE rn BETWEEN ' + CAST(@startRow AS NVARCHAR(20)) + ' AND ' + CAST(@endRow AS NVARCHAR(20)); EXEC sp_executesql @sql; END

调用方式：

EXEC usp_PagedQuery @TableName = 'orders', @OrderByClause = 'created_at DESC, order_id DESC', @Page = 2, @PageSize = 10;

这段代码在小型项目里够用，也不难理解。但我必须泼一盆冷水：这个存储过程只是看起来通用，里面埋着好几个雷。

5.2 存储过程分页里参数嗅探和SQL注入的坑

最大的雷就是SQL注入。上面示例里的@TableName、@OrderByClause、@WhereClause都是直接拼进SQL字符串的。如果这些参数来自用户输入，又没做白名单校验，别人完全可以在参数里塞一段恶意SQL，直接把你整张表删了。业务系统里写这种动态SQL，必须对表名和排序字段做严格白名单过滤，比如：

IF @OrderByClause NOT IN ('created_at DESC', 'created_at ASC', 'order_id DESC') BEGIN RAISERROR('非法排序字段', 16, 1); RETURN; END

第二个坑是参数嗅探。存储过程第一次执行时生成的执行计划会被SQL Server缓存下来，之后再用完全不同的参数走，可能仍然复用第一次的计划。分页场景下，第一页和第一万页的数据量天差地别，如果执行计划被“小分页”固定住，大偏移量查询就可能出现严重的性能回退。针对这个，我常用的做法是给SQL加OPTION (RECOMPILE)，让每次查询重新生成执行计划：

EXEC sp_executesql @sql N'...' , N'...', ... -- 或者在SQL语句末尾加 OPTION (RECOMPILE);

分页这种场景，RECOMPILE带来的编译开销通常远小于选错执行计划的代价，值得用。

5.3 我为什么不建议把分页封装得“太通用”

代码里的通用分页存储过程，我写是写过，但后来慢慢减少了使用的频率。原因不复杂：“通用”和“性能”天生矛盾。一张100万行的订单表和一张1000行的配置表，分页逻辑完全不一样。订单表需要索引、需要选择最优执行计划、可能还要联表查询，配置表直接全表扫描加OFFSET FETCH就行。同一个存储过程给这两种表共用，一定会有一方吃亏。

而且通用存储过程一旦遇到复杂的查询需求就非常难受，比如要分页的同时还要聚合、还要联几张表、还要拼接多个排序字段，这时候动态SQL会越拼越长，可读性越来越差，最后变成一段没人敢动的“祖传SQL”。

现在我更推荐的做法是：能写原生分页SQL就直接写，别套存储过程。每个查询单独写自己的分页逻辑，把表名、排序字段、过滤条件都显式写清楚，一方面利用索引和执行计划更充分，另一方面后来的同事接手也容易看明白。通用封装只适合那种内部管理系统，表结构简单、数据量不大、开发速度优先的场景。

6. 常见问题与排查技巧实录

6.1 分页数据出现重复或丢失

这是我被问得最多的一个问题。明明按创建时间倒序分页，第一页和第二页之间总有几条数据重复，或者中间少了几条。排查思路非常固定：先看排序字段是否唯一。

假设你只按created_at DESC排序，而同一秒里创建了多条订单，数据库在执行时无法区分这些记录之间的先后，行号的分配就会不稳定。第一页查询时，某条记录可能是第9名；第二页查询时，同一批记录排序波动，它就跑到第21名了，于是重复或漏掉。

解决办法很简单：在ORDER BY里加唯一字段，通常是主键。养成习惯，任何分页查询的排序都写成“业务排序字段 + 主键倒序”，比如：

ORDER BY created_at DESC, order_id DESC

这个习惯能让分页结果百分之百确定，也能让索引使用更加稳定。

6.2 排序字段有重复值导致的结果不稳定

和上面类似但更隐蔽的一种情况：排序字段本身业务上允许重复，比如按score DESC排名，或者按status排序。就算加了主键作为次级排序，在某些业务语义下还是会让人觉得“顺序不对”。

比如成绩排行榜，你要取名次前10，但第10名和第11名分数一样。用ROW_NUMBER()或OFFSET FETCH，只能随机挑选其中一条进榜单，用户会质疑为什么同分的人名次不同。这种场景应该用DENSE_RANK()配合TOP WITH TIES来处理，而不是执着于分页。

注意：这是业务语义问题，不是SQL语法问题。分页本身要求“每一行都有唯一位置”，而同分排名要求“同分并列”，这两个需求是冲突的。遇到同分并列需求，别再纠结怎么改排序字段了，直接换个函数来写。

6.3 大偏移量查询越来越慢

分页页数越深，查询越慢，这是OFFSET和ROW_NUMBER()方案的共同痛点。数据库必须计算出所有偏移量之前的行，再丢弃它们，偏移量越大，浪费的算力越多。比如10万条数据，每页20条，你要看第5000页，数据库就得先算出前10万条行的编号，这是没有捷径的。

针对这个问题的实用解法有几个：

第一种是延迟关联。先用最短的字段结构查出当前页的主键，再回表取完整数据，避免在大字段上做大量排序：

SELECT o.* FROM orders o INNER JOIN ( SELECT order_id FROM orders ORDER BY created_at DESC, order_id DESC OFFSET 99980 ROWS FETCH NEXT 20 ROWS ONLY ) t ON o.order_id = t.order_id ORDER BY o.created_at DESC, o.order_id DESC;

第二种是键集分页，也就是基于上一页最后一条记录继续翻页。比如当前页最后一个是order_id = 12345, created_at = '2024-01-01 10:00:00'，下一页就直接查比这个组合更小的记录：

SELECT TOP 20 * FROM orders WHERE (created_at < '2024-01-01 10:00:00') OR (created_at = '2024-01-01 10:00:00' AND order_id < 12345) ORDER BY created_at DESC, order_id DESC;

这种方式无论翻到多深，都只走索引查20条，性能非常稳定，但缺点是不能直接跳页码，只适合“上一页下一页”的场景。

6.4 参数化SQL和排序方向的处理

项目里写分页，建议别直接拼字符串传值，而是用sp_executesql参数化查询。好处不只是防注入，还能让SQL Server更容易复用执行计划，减少编译开销。比如：

EXEC sp_executesql N'SELECT * FROM orders ORDER BY created_at DESC, order_id DESC OFFSET @offset ROWS FETCH NEXT @pageSize ROWS ONLY', N'@offset INT, @pageSize INT', @offset = 20, @pageSize = 10;

还有一个容易被忽视的细节是排序方向。很多人在实现“点击表头切换升降序”功能时，喜欢把DESC或ASC直接拼进排序字段，这很容易被SQL注入。安全一点的思路是用CASE做映射，比如：

ORDER BY CASE WHEN @sortDir = 'asc' THEN created_at END ASC, CASE WHEN @sortDir = 'desc' THEN created_at END DESC, order_id DESC;

虽然执行计划可能不如直接写死排序方向那么简洁，但安全性和参数化程度高很多，业务系统里完全够用。

说起来，我最早接触SQL Server分页时，也是到处找“SQL Server LIMIT怎么写”的教程。后来在不同的版本、不同的项目里反复折腾，才发现分页这件事本质上不是语法问题，而是对排序稳定性、索引设计、性能取舍的综合考量。你现在手里的是什么版本、业务需要的是哪种分页方式、有没有大字段需要延迟关联，这些想清楚了，SQL怎么写自然就清晰了。顺便分享一个我个人的习惯：任何分页查询，写完先看一眼执行计划，确认排序字段走的是索引而不是排序算子，这能帮你避开一大半性能问题。