MySQL 8.0+ 应优先使用 ROW_NUMBER() 窗口函数，需严格配合 OVER(ORDER BY ...) 或 OVER(PARTITION BY ... ORDER BY ...)，否则报错或序号不可预测；5.7及更早版本须用用户变量并确保排序与变量初始化在同子查询中。
MySQL 8.0+ 直接用 ROW_NUMBER() 最稳
如果你用的是 MySQL 8.0 或更新版本，ROW_NUMBER() 是最可靠、语义最清晰的方式。它不依赖会话变量的执行顺序，也不受 ORDER BY 子句位置影响，和标准 SQL 行为一致。
常见错误是写成 SELECT ROW_NUMBER() OVER() AS rn, ... —— 没有 ORDER BY 会导致序号“随机”（实际是按引擎返回顺序，不可预测）。
-
ROW_NUMBER()必须搭配OVER(ORDER BY ...)，否则报错 - 想按多字段排序？写成
OVER(ORDER BY status DESC, created_at ASC) - 如果要分组编号（比如每类商品独立编号），用
OVER(PARTITION BY category_id ORDER BY price) - 性能上，
ROW_NUMBER()会触发临时表或文件排序，大结果集注意加好索引
MySQL 5.7 及更早：用用户变量模拟，但必须小心顺序
老版本没窗口函数，只能靠 @rownum := @rownum + 1 这类变量。但它极易出错——MySQL 不保证 SELECT 中变量赋值与行处理的先后顺序，尤其当有 ORDER BY 或 LIMIT 时。
正确写法必须把排序和变量计算“锁死”在同一个子查询里：
SELECT @rownum := @rownum + 1 AS rn, t.*
FROM (SELECT * FROM users ORDER BY id) t,
(SELECT @rownum := 0) r;常见翻车点：
- 直接写
SELECT @rownum := @rownum + 1, * FROM users ORDER BY id→ 序号可能乱序 - 漏初始化变量（
(SELECT @rownum := 0)）→ 第一次运行可能是 NULL，导致整列变 NULL - 在存储过程或连接复用场景中，变量未重置 → 上次查询的值残留
- 用在视图里基本不可靠，因为视图不保证执行上下文
别用 (SELECT COUNT(*) ...) 自关联来“模拟序号”
有人会写 SELECT (SELECT COUNT(*) FROM t2 WHERE t2.id 。这在小表上看似能跑，但它是 O(n²) 复杂度，1 万行就可能卡住。
真正的问题不只是慢：
- 没有索引时，每行都全表扫描一次，磁盘 I/O 爆增
- 即使
id有主键，优化器也可能不走索引（尤其带其他条件时） - 并发查询下，COUNT 结果可能被事务隔离级别干扰（如可重复读下看到旧快照）
- 无法和
LIMIT安全配合——你想要前 10 条带序号？它仍会算完整张表
自增序号不是主键，别把它当唯一标识用
无论用哪种方式生成的序号，它只是查询时的临时标记，不持久、不唯一、不索引友好。最容易被忽略的一点是：
- 同一语句反复执行，序号可能不同（比如
ORDER BY字段有重复值且没加二级排序） - 导出 CSV 后再导入，这个序号就彻底失效了
- 应用层分页时，如果前端靠序号做“第 N 条”，而服务端用
LIMIT offset, size，两者对不上 - 真需要稳定编号？要么加个真实自增列，要么用应用层 UUID + 时间戳生成逻辑 ID
