row_number()需配合partition by user_id order by created_at使用，确保按用户分组并依业务时间排序生成连续序号；漏写partition by或误用id排序会导致逻辑错误，mysql 8.0+原生支持，旧版本应升级或预过滤后用可靠替代方案。
用 ROW_NUMBER() 按用户分组排序
直接用 ROW_NUMBER() 配合 PARTITION BY user_id ORDER BY created_at 就能算出每个用户订单的自然序号。关键不是“全局第几单”，而是“这个用户自己的第几单”——所以必须按 user_id 分区，且排序字段得是下单时间（比如 created_at），不能用主键 id，否则可能因插入乱序导致序号错乱。
常见错误：漏写 PARTITION BY，结果变成全表连续编号；或者用 ORDER BY id，但订单表有补单、迁移或批量导入，id 并不反映真实下单顺序。
- 确保排序字段是业务上定义“先后”的依据，通常是
created_at或order_time - 如果存在同一用户同秒下单多笔，需追加二级排序，例如
ORDER BY created_at, id -
ROW_NUMBER()严格保证 1,2,3… 不跳号，适合做“第1单、第2单”这类序号
需要去重或合并订单时用 DENSE_RANK()
如果一个用户某天下了 3 笔状态为“已取消”的测试单，你只想把有效订单（如 status IN ('paid', 'shipped')）计入序号，就得先过滤再编号。这时候如果还用 ROW_NUMBER()，序号是连续的，但若想体现“这是该用户的第2次成功下单”，而不管中间有多少无效单，就该用 DENSE_RANK() —— 它对相同排序值不跳号，但这里更常见的是先 WHERE 过滤再 ROW_NUMBER()。
真正要用 DENSE_RANK() 的场景是：同一用户同一天有多笔有效订单，且你希望它们共享同一个序号（比如按日期聚合后编号）。但绝大多数“历史第几单”需求不需要这样，强行用反而容易混淆。
- 优先用
WHERE status NOT IN ('cancelled', 'draft')预过滤，再套ROW_NUMBER() -
DENSE_RANK()在ORDER BY值相同时给相同序号，适合按日期/金额分组编号，不是默认选择 - 避免在未过滤的原始表上直接
DENSE_RANK() OVER (PARTITION BY user_id ORDER BY DATE(created_at))，会把取消单也卷入日期分组
MySQL 8.0+ 和 PostgreSQL 直接支持，旧版 MySQL 得绕行
MySQL 5.7 及更早版本不支持窗口函数，硬要用序号就得靠自连接或变量。但变量方式（如 @row := @row + 1）在复杂查询、多线程或优化器重排时行为不可靠，官方文档已明确标注“不推荐用于生产”。PostgreSQL 8.4+ 和 MySQL 8.0+ 都稳定支持 ROW_NUMBER()，别为兼容老版本牺牲可读性和正确性。
- 确认数据库版本：
SELECT VERSION();（MySQL）或SELECT version();（PostgreSQL） - MySQL 5.7 若无法升级，用子查询关联计数（性能差但确定）：
(SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id AND o2.created_at - 别信网上“SET @row:=0; SELECT @row:=@row+1”的方案，ORDER BY 和变量赋值顺序在不同执行计划下可能错乱
注意 NULL 和时区对排序的影响
created_at 为空（NULL）会导致该行在 ORDER BY 中被排到最前或最后（取决于数据库默认），进而让序号错位。比如用户首单 created_at 为 NULL，它会被标为第1单，实际却不是。另外，如果应用写入的是本地时间但数据库存 UTC，而多个地区用户混在一个表里，ORDER BY created_at 可能跨时区颠倒真实先后。
- 查一遍：
SELECT COUNT(*) FROM orders WHERE created_at IS NULL AND user_id = ?，空值必须修复或排除 - 统一时间存储规范：所有写入都转为 UTC，应用层负责展示时区转换
- 如果业务强依赖“用户本地时间顺序”，得额外存
local_created_at字段并按其排序，不能只靠服务器时间
