子查询生成序列号本质是行号计算，需通过统计排序条件更小的行数加1实现，依赖唯一有序字段避免重复或跳号，性能差且不支持分组编号，现代数据库应优先使用ROW_NUMBER()窗口函数。
子查询生成序列号的本质是行号计算
SQL标准不直接支持“为每一行动态生成序列号”这种需求，所谓序列号其实是行号（row number），必须依赖窗口函数或自连接模拟。纯子查询方式在MySQL 5.7或SQL Server 2005之前常见，但性能差、逻辑绕，且无法处理重复值或排序不稳定的情况。
如果你坚持用子查询（比如受限于旧版MySQL或某些嵌入式数据库），核心思路是：对当前行，统计“排序条件更小的行数 + 1”。这要求主表有明确可比较的排序字段（如id、created_at），否则结果不可靠。
- 必须有唯一且有序的参照列，否则子查询会算出相同序号甚至跳号
- 子查询需关联外层表，用
WHERE限定比较范围，不能漏掉AND连接条件 - 若排序字段存在重复值，多个行会得到相同序号（不是严格递增）
MySQL 5.7及以下：用相关子查询模拟ROW_NUMBER()
这是最典型的“子查询生成序列号”场景。假设表orders按order_date升序编号，且id唯一：
SELECT
(SELECT COUNT(*) FROM orders o2
WHERE o2.order_date < o1.order_date
OR (o2.order_date = o1.order_date AND o2.id < o1.id)) + 1 AS rn,
o1.order_id, o1.order_date
FROM orders o1
ORDER BY o1.order_date, o1.id;
注意这里用了复合条件o2.order_date = o1.order_date AND o2.id 来打破并列，避免序号重复。如果没这个<code>id字段，仅靠order_date就无法保证全序，结果可能非确定。
- 每行执行一次子查询，数据量大时性能急剧下降（O(n²)）
- MySQL 5.7默认不支持窗口函数，这是无奈但可行的兜底方案
- 不能在
WHERE或HAVING中引用该子查询别名rn，只能用于SELECT和ORDER BY
PostgreSQL / SQL Server / MySQL 8.0+：直接用窗口函数替代子查询
所有现代SQL引擎都支持ROW_NUMBER()，它比子查询快一个数量级，语义清晰，且天然支持PARTITION BY分组编号。强行用子查询反而增加维护成本。
等价写法（推荐）：
SELECT ROW_NUMBER() OVER (ORDER BY order_date, id) AS rn, order_id, order_date FROM orders;
-
ROW_NUMBER()保证严格递增，即使排序字段重复也分配不同序号 - 子查询无法实现
PARTITION BY category ORDER BY price这类分组内编号，窗口函数一行搞定 - 在MySQL 8.0+中，子查询方案仍能运行，但执行计划会显示全表扫描+嵌套循环，而窗口函数走索引+一次扫描
容易被忽略的边界问题
很多人以为加个ORDER BY就能让子查询序号“看起来正常”，但实际部署时经常出错：
- 子查询里漏写
ORDER BY对应的字段约束，导致计数逻辑断裂（例如只比order_date，忽略同日期多条记录） - 在
GROUP BY后试图用子查询生成序号——此时子查询看到的是聚合后的结果集，o2表别名已不可见 - 把子查询放在
WHERE条件里过滤序号（如WHERE rn > 10），语法报错，因为rn是SELECT阶段产物，WHERE阶段不可见 - 使用
UNION合并结果后加子查询编号，子查询无法跨UNION分支感知全局顺序
真正需要动态序列号时，优先确认数据库版本是否支持窗口函数；若不支持，再用子查询，且务必用唯一字段补全排序逻辑——否则序号只是幻觉。
