MySQL 8.0+ 应直接使用 ROW_NUMBER()，它基于逻辑排序生成连续序号，稳定可靠；必须在 OVER() 中指定 ORDER BY（如 ROW_NUMBER() OVER (ORDER BY id)），缺则报错；分组编号需加 PARTITION BY；不可在同级 WHERE 中引用序号列，须用子查询包裹过滤。
MySQL 8.0 直接用 ROW_NUMBER() 最稳
如果你用的是 MySQL 8.0+，别折腾用户变量了——ROW_NUMBER() 是标准、可靠、可预测的方案。它按指定排序生成连续整数序号，不会因查询优化器重排执行顺序而错乱。
常见错误是写成 ROW_NUMBER() OVER ()（缺 ORDER BY），这在 MySQL 中会报错：Window 'w' lacks an ORDER BY clause。窗口函数必须明确排序依据，否则序号无意义。
实操建议：
- 始终在
OVER()中写ORDER BY，哪怕只是按主键排序，例如：ROW_NUMBER() OVER (ORDER BY id) - 如果要分组编号（比如每类商品内单独编号），用
PARTITION BY：ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) - 避免在子查询或视图里嵌套多层窗口函数，MySQL 8.0 对复杂窗口表达式优化有限，可能触发临时表或性能下降
MySQL 5.7 只能靠变量，但必须加 ORDER BY 强制排序
5.7 不支持窗口函数，很多人用 @rownum := @rownum + 1，结果序号和预期对不上——根本原因是：MySQL 在没有显式 ORDER BY 时，不保证 SELECT 的行返回顺序，变量累加就“加到空气里”了。
正确做法是把排序固化在派生表里，再在外面套变量：
SELECT @rownum := @rownum + 1 AS row_num, t.*
FROM (SELECT * FROM users ORDER BY created_at DESC) t,
(SELECT @rownum := 0) r;注意点：
-
ORDER BY必须出现在子查询中，不能只写在外层；否则变量仍会按存储引擎物理顺序累加 - 初始化变量
(SELECT @rownum := 0)要作为 JOIN 表参与，不能写成SET @rownum = 0再查——后者在某些客户端或连接池下不生效 - 该写法在
GROUP BY或含聚合的查询中容易失效，因为派生表可能被优化掉，优先考虑升级到 8.0
ROW_NUMBER() 和变量实现的序号行为差异
表面都是“加序号”，但底层逻辑完全不同：窗口函数基于逻辑排序结果生成序号；变量依赖语句执行时的行处理顺序，属于过程式计算。
这意味着：
- 相同 SQL 在不同 MySQL 版本/配置下，变量方式可能返回不同序号（尤其涉及索引跳过、ICP 优化时）
-
ROW_NUMBER()支持RANK()、DENSE_RANK()等变体，变量模拟起来极难且易错 - 带
LIMIT时更危险：变量方式若先 LIMIT 再排序，序号从 1 开始但数据不是你想要的那批；而ROW_NUMBER()先排序再编号最后 LIMIT，结果可控
别在 WHERE 里引用序号列（无论哪种方式）
有人想写 WHERE row_num BETWEEN 10 AND 20 做分页，这是错的。序号是查询结果的衍生列，不能在同级 WHERE 中过滤——MySQL 会报错 Unknown column 'row_num' in 'where clause'。
正确做法只有两种：
- 用子查询包裹：
SELECT * FROM (SELECT ROW_NUMBER() OVER (...) AS rn, ...) t WHERE t.rn BETWEEN 10 AND 20 - 用
LIMIT+OFFSET（但注意深分页性能问题，尤其变量方式下 OFFSET 越大越慢）
变量方式还额外多一个坑：如果子查询里用了 LIMIT，必须确保 ORDER BY 和变量初始化都在同一层级，否则序号可能不连续。
