企业官网建设流程全解析

你有没有遇到过这种场景：查出来的订单列表要在前端表格里加一列“序号”，或者导出 Excel 时希望第一列是 1、2、3…… 这样的行号，又或者调试一条几百行结果的 SQL 时，只想快速定位“第 87 行那笔数据”到底长什么样。MySQL 默认只会把查询结果一列一列吐出来，行号这种“元信息”是不会自动附带的。这个需求听上去很小，但真写起来，坑一点都不少——尤其碰上排序、分页、分组这些组合条件，写法稍微不对，序号就会给你表演“乾坤大挪移”。这篇文章把我这些年给 MySQL 查询结果加序号的几种做法、原理和踩坑记录整理成一份可以直接照着抄的笔记，从 5.7 时代的变量方案一路聊到 8.0 的窗口函数。

1. 给查询结果加序号：这个需求比你想的更常见

1.1 一张“带编号的结果集”能干什么

先搞清楚为什么需要给查询结果加序号，因为很多同学一开始以为只是“锦上添花”，实际上这是个非常硬的业务需求。

最典型的是报表导出。财务月底导出明细账，业务方拿到 Excel 第一句话就问：“怎么没有行号？我上万行怎么核对？”这时候你要么在 SQL 里把行号算出来，要么在代码里循环补一个序号列。前者更干净，一次查询到位，结果集落 Excel 就是现成的表头和数据，不用再写一遍循环。

其次是前端表格展示。现在很多后台管理系统列表里都会有一列“序号”，它是用户定位数据的重要锚点。用户说“第 5 条数据有问题”，如果页面上没有行号，你得从前端到后端再到数据库，来回数半天才知道他指的是哪一行。有了序号，沟通成本直线下降。

还有一类是调试和定位。我自己排查慢 SQL 或数据异常时，经常会在临时查询里加一个行号列，然后配合LIMIT快速抽样看某一段数据。比如怀疑第 1000 行附近数据有异常，直接LIMIT 990, 20加行号一看，比抓瞎翻结果集高效得多。

1.2 先分清你要的是哪种序号

别看都是“序号”，其实有两种完全不同的语义，写 SQL 之前必须先想清楚是哪种。

第一种是物理行号。它表示的是“结果集按物理存储或原始返回顺序的第几行”，跟任何业务排序都无关。这种需求很少见，一般只在调试底层数据时用到。

第二种是逻辑行号。它表示的是“结果集按某个业务规则排序之后，这一行排在第几”，比如按成绩从高到低排，第一名是 1，第二名是 2。这才是真正的业务需求，也是绝大多数人想要的。

很多新手踩坑，就是把这两种搞混了。你明明想要逻辑行号，却写了一个只给物理行号的 SQL，最后排序一变，序号全乱。更关键的是，MySQL 和 Oracle 不一样，Oracle 里自带一个ROWNUM伪列，但 MySQL没有内置的行号伪列，5.7 及以下版本连窗口函数都没有，所以所有序号都是“自己动手造”。怎么造，这就是下面要聊的重点。

提示：MySQL 8.0 之前，想给查询结果加序号，主流方案是“用户变量自增”；8.0 之后，ROW_NUMBER()窗口函数是最优解。两套方案都要会，因为你不知道线上环境到底跑的是哪个版本。

2. MySQL 5.7 及以前的标准答案：用户变量自增

2.1 SET 初始化的两段式写法

在 MySQL 5.7 及更早版本里，给查询结果加行号最经典的做法是用用户变量自增。思路很简单：定义一个变量，从 0 开始，每查出一行就让变量加 1，然后把加好的值作为序号列输出。

SET @row_num := 0; SELECT @row_num := @row_num + 1 AS row_num, name, score FROM student;

这里有个关键细节：赋值运算符是:=，不是=。在SELECT列表里，=会被当作比较运算符，只有:=才表示赋值。如果你写成@row_num = @row_num + 1，它不会报错，但结果永远是 NULL，因为@row_num初始为 NULL，NULL = NULL + 1最终结果是 NULL，条件不成立，序号根本加不出来。

为什么要先SET @row_num := 0？因为用户变量在没有初始化的时候默认值是 NULL，而NULL + 1还是 NULL。不初始化直接累加，整列都会是 NULL，等于白写。这个初始化语句必须在同一个数据库连接里先于查询执行，如果是在命令行客户端或图形化工具里分两次执行，只要保证是同一个会话就没问题。

2.2 派生表初始化：一条 SQL 搞定

两段式写法有个不方便的地方：很多应用框架里，一条SELECT能搞定的事，你要先单独执行一条SET，在 ORM 场景下就得拆成两条语句，不够优雅。

解决办法是把初始化动作塞进派生表，用CROSS JOIN的方式让变量在查询开始时就被赋值：

SELECT @row_num := @row_num + 1 AS row_num, s.name, s.score FROM student AS s CROSS JOIN (SELECT @row_num := 0) AS init;

这条语句里，(SELECT @row_num := 0) AS init就是充当“初始化器”的派生表。MySQL 会先把这条子查询物化成一个常量表，里面只有一行一列，值为 0，然后和student表做笛卡尔积。因为派生表只有一行，所以笛卡尔积不会改变student的行数，每一行拿到@row_num都是同一个初始值 0，再逐步累加。

注意：派生表必须有别名。写成(SELECT @row_num := 0)而不加AS init，MySQL 直接报错：Every derived table must have its own alias。这个错误太常见了，几乎每个用派生表的初学者都撞过。

2.3 变量方案里最容易忽略的三件事

用变量加序号，看起来简单，实际上有三个容易被忽略的坑。

第一，用户变量是会话级的。@row_num不是全局变量，也不是局部变量，它属于当前数据库连接。同一个连接里，你前面执行过的SET会一直保留。这带来两个问题：一是连接池复用时，上一次查询可能已经把这个变量改成了某个值，如果你这次查询没有重新初始化，起始值就不对；二是如果你用图形化工具开了两个查询窗口，互不影响，但如果你在代码里用了同一个连接，前后两次查询之间变量状态会“残留”。这就是为什么我强烈建议在每条查询里都做初始化，要么SET，要么派生表，千万别指望上一次执行完变量会自动归零。

第二，变量的累加次数取决于实际返回的行数。@row_num := @row_num + 1是在SELECT阶段对每一行求值的，所以如果WHERE条件过滤掉了大量行，序号会在过滤之后的结果集上连续编号，而不是在原始表上编号。这既是对的，也容易让人误会——你看到的第一行序号是 1，不代表它在表里的物理偏移是 1。

第三，不要在同一条语句里多次读写同一个变量。MySQL 官方文档明确说过，用户变量在同一语句里的求值顺序是未定义的。你去查资料，会看到有人用@row_num := @row_num + 1同时配合@prev_class这种多变量交互写法做分组序号，能跑通，但那是“凑巧”，换个版本、换个执行计划就可能翻车。能用窗口函数的场景，尽量别碰这种高危写法。

3. 排序后再编号：变量方案最容易踩的坑

3.1 翻车现场还原

这个坑我敢说 80% 用过变量加序号的人都踩过。需求很普通：要给学生按成绩从高到低加个排名序号。于是你非常自然地写了：

SET @row_num := 0; SELECT @row_num := @row_num + 1 AS row_num, name, score FROM student ORDER BY score DESC;

期望的结果是成绩最高的人序号是 1，第二高的是 2。但实际跑出来往往是这样：排序确实按成绩从高到低排好了，但序号列根本没有跟着排，是乱的。

模拟一个例子，原始表数据如下：

如果你期望按成绩排序后再编号，结果应该是：

但很多版本实际跑出来，序号列还是按id的原始顺序累加的：E 显示序号 5，B 显示序号 2，D 显示序号 4。问题就出在你在SELECT里直接对变量赋值，却指望它按ORDER BY之后的顺序工作。

3.2 为什么变量方案在 ORDER BY 面前“不听话”

要理解这个坑，得先搞清楚 SQL 的逻辑执行顺序。

从逻辑上讲，一条查询的执行大致是：FROM->WHERE->GROUP BY->HAVING->SELECT->DISTINCT->ORDER BY->LIMIT。也就是说，SELECT列表里的表达式，是在ORDER BY排序之前计算的。当你写@row_num := @row_num + 1 AS row_num时，MySQL 实际上是在逐行读取数据、还没有做最终排序的时候，就把每一行的@row_num累加好了。等到ORDER BY score DESC真正执行时，序号列的“值”已经定型，排序只是把这一行连同它的序号一起挪到对应位置，序号当然不会跟着重置或回退。

更麻烦的是，MySQL 文档对用户变量赋值和读取的顺序不做任何保证。意思是，即使你现在测出来是“先累加后排序”，也不代表所有版本、所有数据量下都这样。可能某些场景下优化器选择不同的执行计划，变量累加的顺序就变了。这也是为什么我建议别在生产 SQL 里依赖变量求值的具体顺序。

3.3 正确姿势：先排序，后编号

知道了原因，解决办法就很清晰了：让排序先发生，编号在排序之后的结果上进行。

具体做法是把排序放进子查询，让子查询先把结果排好序，外层再对这个“已经排好序的结果集”做变量累加：

SELECT @row_num := @row_num + 1 AS row_num, t.name, t.score FROM ( SELECT name, score FROM student ORDER BY score DESC ) AS t CROSS JOIN (SELECT @row_num := 0) AS init;

这里的关键在于：子查询t会先完成ORDER BY score DESC的排序，并把排序后的结果作为派生表物化出来；外层SELECT扫描这个派生表时，行顺序已经是按成绩降序排好了的，所以变量累加出的序号正好和顺序一致。

这个“先排序、后编号”的顺序，是 5.7 时代所有变量方案的总纲。不管是普通排序、分页还是分组，只要你能保证“编号之前的顺序已经稳定”，结果基本不会错。

提示：如果还想在排序好的基础上加上LIMIT，顺序更要注意。LIMIT在逻辑执行顺序里排在最后，所以如果你想“先取前 10 条，再编号”，就要把LIMIT放进子查询；如果你想“全局编号，只取第 10 到 20 行”，就要先编号再分页，两种需求写法完全不同，详见第 5 章。

4. MySQL 8.0 的窗口函数：一步到位的仪式感

4.1 ROW_NUMBER() 的基本用法

MySQL 8.0 推出窗口函数之后，给查询结果加序号这件事，终于有了一个“官方正解”，它就是ROW_NUMBER()。

最基本的用法长这样：

SELECT ROW_NUMBER() OVER (ORDER BY score DESC) AS row_num, name, score FROM student;

这条 SQL 的意思非常直白：对student表按score降序排列，然后给每一行分配一个从 1 开始连续递增的序号。它彻底解决了变量方案“先编号还是先排序”的纠结，因为OVER里的ORDER BY score DESC就是用来定义“按什么顺序编号”的，顺序定义和编号计算是同一个逻辑，天然一致。

需要特别注意一点：OVER里的ORDER BY只负责决定窗口函数的计算顺序，它不代表整个查询最终展示的顺序。如果想让查询结果最终也按分数降序展示，你还是要在最外层再写一个ORDER BY score DESC，或者干脆写两次。少写一个外层排序，结果行顺序可能是乱的，只是序号计算正确，一眼看过去会非常困惑。

4.2 变量方案和窗口函数怎么选

现在很多公司线上环境还是 MySQL 5.7，窗口函数用不了，所以变量方案不能丢。但只要能上 8.0，新写的 SQL 我建议一律用窗口函数。两者的差异很明显：

从性能和可维护性两个角度看，窗口函数都是更优解。尤其当你需要在结果集上做分组序号、去重取第一条这类操作时，窗口函数的表达能力比变量方案高出一个等级，代码量少、出错率低。变量方案更像是“螺蛳壳里做道场”，它是旧版本里没得选的办法，能跑但不好维护。

4.3 并列排名：RANK() 与 DENSE_RANK()

给查询结果加序号时，很多人其实想表达的是“排名”而不是“行号”。排名有一个绕不开的场景：成绩并列怎么办？

窗口函数一族里，除了ROW_NUMBER()，还有RANK()和DENSE_RANK()，三者看起来像，语义差很多。假设四名学生的成绩是 100、100、90、80，三种函数的输出分别是：

如果只是要表格里的“第几行”，用ROW_NUMBER()；如果是“排名”，通常用RANK()或者DENSE_RANK()，看业务要不要跳号。比如竞赛排名，两个人并列第一，下一个人就是第三名，用RANK()；人事绩效里，并列之后下一个人是第二名，用DENSE_RANK()。

这三个函数的语法完全一样，都是函数名() OVER (ORDER BY ...)，想并列排序就看OVER里的ORDER BY字段是否相同。

5. 分页、分组、多表场景逐个拆解

5.1 分页查询：全局序号和每页序号都想要

分页场景下，序号有两种截然不同的需求，写法也是两条路。

需求一：全局序号。比如一个列表一共 10000 条，每页 20 条，用户翻到第 100 页，希望看到序号是 1981 到 2000，而不是这一页从 1 开始。这个需求的做法是“先编号，再分页”：

SELECT row_num, name, score FROM ( SELECT ROW_NUMBER() OVER (ORDER BY score DESC) AS row_num, name, score FROM student ) AS t LIMIT 20, 20;

内层先给全量结果编好全局序号，外层再LIMIT取某一页，这样拿到的序号就是全局连续整数，完美满足“翻到第几页也能知道总数第几行”的需求。

需求二：每页从 1 开始。很多后台系统的表格就是这样，每页都从 1 编号，页码之间互不相干。这就要反过来，“先分页，再编号”：

SELECT ROW_NUMBER() OVER (ORDER BY score DESC) AS row_num, name, score FROM ( SELECT name, score FROM student ORDER BY score DESC LIMIT 20, 20 ) AS page_data;

内层先做排序和分页，把这一页的 20 行取出来；外层再对这 20 行做ROW_NUMBER()，自然每页都从 1 开始。注意内层的ORDER BY score DESC必须保留，否则“哪 20 条”就不对了。

如果是 5.7 的变量方案，对应“先分页再编号”的写法长这样：

SELECT @page_num := @page_num + 1 AS row_num, page_data.name, page_data.score FROM ( SELECT name, score FROM student ORDER BY score DESC LIMIT 20, 20 ) AS page_data CROSS JOIN (SELECT @page_num := 0) AS init;

逻辑和窗口函数版本完全一致：先取到这一页的行，再对行累加序号。

5.2 分组内编号：PARTITION BY 一行搞定

另一个高频需求是分组内编号。比如每个班级内部按成绩排个名次，输出“班级内第几名”。如果用 5.7 变量方案，你得同时维护两个变量，一个记总序号，一个记上一个分组值，然后每行判断：如果班级变了，序号重置为 1，否则继续累加。写法极其脆弱：

SET @class_rank := 0; SET @prev_class := NULL; SELECT @class_rank := IF(@prev_class = class_id, @class_rank + 1, 1) AS class_rank, @prev_class := class_id AS class_id, name, score FROM student ORDER BY class_id, score DESC;

这个 SQL 的写法依赖两个变量在同一行的求值顺序，属于“当前版本能跑，但 MySQL 官方不保证”的典型高危写法。一旦优化器执行计划变化，结果就是错的。

窗口函数方案就简单得多，PARTITION BY这个关键词天生就是干这个的：

SELECT ROW_NUMBER() OVER (PARTITION BY class_id ORDER BY score DESC) AS class_rank, class_id, name, score FROM student;

PARTITION BY class_id表示按班级分组，然后每个组内部再按score DESC编序号，组与组之间互不干扰。读起来像人话，写起来不用维护任何变量，强烈推荐。

5.3 JOIN、UNION、子查询里的序号

多表查询里加序号，很多人会犹豫：是加在 JOIN 之前还是之后？其实顺序很简单——先得到最终的结果集，再对结果集编号。

比如订单表和用户表 JOIN，你想按下单时间排序后给最终结果加序号：

SELECT ROW_NUMBER() OVER (ORDER BY o.order_time DESC) AS row_num, o.order_id, u.user_name, o.order_time FROM orders AS o JOIN users AS u ON o.user_id = u.user_id;

不管是 JOIN 还是多表嵌套，序号永远作用在“已经算好的最终结果集”上，不要试图在 JOIN 之前先给某个子表加序号再带出去，那基本没有意义。

UNION 场景有一点特殊。UNION默认会去重，会把多个SELECT的结果合并成一个集合，这时如果直接在外面加ROW_NUMBER()，序号是对合并后的整体编的，没问题。但如果你希望“每个分支各自从头编号”，就麻烦了——这本质上又变成分组编号，没有分组字段就做不到。实际业务里通常都是前者。另外，如果你用UNION ALL保留了所有分支的行，再统一编号，序号就是全量连续递增，这个最适合做“合并报表导出”的场景：

SELECT ROW_NUMBER() OVER (ORDER BY create_time DESC) AS row_num, t.* FROM ( SELECT id, create_time, '订单' AS source FROM orders UNION ALL SELECT id, create_time, '售后' AS source FROM after_sales ) AS t;

5.4 NULL 排序、重复数据与结果集消耗

最后聊几个容易被忽略的边界细节。

NULL 值的排序位置。MySQL 默认把 NULL 当作“比任何非 NULL 值都小”。所以ORDER BY score DESC时，所有 NULL 会排在最后面；ORDER BY score ASC时，NULL 排在最前面。如果你希望 NULL 的排位可控，可以显式写ORDER BY (score IS NULL), score DESC，这样非 NULL 先排，NULL 一定垫底。这个规则对窗口函数同样生效，因为窗口函数里的ORDER BY用的是同一套排序逻辑。

重复数据下的序号稳定性。ROW_NUMBER()在遇到完全相同排序键时，哪个先哪个后是不保证的。如果业务上必须让相同成绩的行也有稳定顺序，比如“同成绩按学号小的优先”，需要在OVER里追加次级排序键：

ROW_NUMBER() OVER (ORDER BY score DESC, id ASC)

大结果集的消耗。不管是变量方案还是窗口函数，只要加了排序，就绕不开排序成本。ROW_NUMBER()对百万行结果排序时，会占用内存临时表，量大时甚至会落到磁盘临时表，整体性能和资源消耗都要心里有数。不过相比之下，窗口函数交给优化器统一调度，通常比逐行变量累加更可控。

6. 几条踩出来的实操心得

写到这里，把这么多年跟 MySQL 序号打交道的心得浓缩成几条，都是踩过坑之后才记住的。

第一条，先确认版本再决定方案。拿到需求先执行SELECT VERSION();，8.0 以上直接用窗口函数，5.7 及以下老老实实写变量，但必须遵守两条顺序铁律：先排序后编号、先编号后分页。不搞清楚版本就套模板，是最大的坑。

第二条，能不用变量就别用变量。用户变量最让人头大的地方是“求值顺序未定义”，今天能跑出正确结果，不代表换个环境还正确。我见过因为升级小版本后序号乱掉而半夜起来排查的案例。窗口函数虽然在旧版本用不了，但只要版本允许，它就是最稳的选择。

第三条，派生表一定要起别名。这条看着不起眼，但新手基本都会漏，Every derived table must have its own alias这个报错我不知道看过多少遍。加一个AS init、AS t、AS page_data，不费事，但能少一次报错。

第四条，连接池环境里用变量要格外小心。如果你的应用用了连接池，同一个连接可能被多个请求复用，上一条 SQL 执行完的@row_num不会自动清空。最稳妥的做法是永远把初始化放进同一条 SQL 里，也就是CROSS JOIN (SELECT @row_num := 0)这种写法，别用两段式的SET。

第五条，序号应该由 SQL 生成，而不是代码循环补。我见过很多后端同学图省事，先查数据，然后在 Java 或 Python 里循环加一个序号列。短期看没问题，但一旦涉及分页、分组、聚合，代码里补的序号非常容易和真实顺序对不上。把序号放回 SQL，结果集是什么样，最终输出就是什么样，逻辑单一，不容易出岔子。

最后分享一个小技巧：我会把“给结果集加序号”做成一个固定模板。凡是需要导出明细、前端列表展示的查询，都统一写成窗口函数开头，5.7 环境则统一用派生表初始化变量。这样团队里任何人接手，一看开头就知道这个查询是带序号的，不用每次从头推理逻辑。排查问题时，也少了很多“顺序为什么不对”的争论——顺序一旦在到达编号那一步之前就不稳定，一切序号都是空谈。这句话，送给所有在 MySQL 里和序号较过劲的人。