ROW_NUMBER()配合PARTITION BY可实现年度内独立编号，即每年从1开始递增、跨年自动重置；必须用PARTITION BY year分组，ORDER BY指定年内排序依据，且需注意年份提取兼容性与排序唯一性。
用 ROW_NUMBER() 配合 PARTITION BY 实现年度内独立编号
核心就是让编号在每年内部从 1 开始递增，跨年自动重置。关键不在“增长”，而在“按年切片重算”。ROW_NUMBER() 是唯一能保证严格连续整数的窗口函数，RANK() 和 DENSE_RANK() 在有重复排序值时会跳号或并列，不满足“自动增长”要求。
常见错误是只写 ORDER BY year, id 却漏掉 PARTITION BY year，结果得到的是全表连续编号，不是每年重置。
- 必须把年份字段（如
EXTRACT(YEAR FROM order_date)或YEAR(order_date)）放进PARTITION BY - 排序依据要明确：若想按时间先后编号，就
ORDER BY order_date；若想按主键顺序，就ORDER BY id - 注意字段类型：如果年份存的是字符串（如
'2023'），直接PARTITION BY year没问题；但若用日期函数生成，确保不带时分秒干扰分组（EXTRACT(YEAR FROM ...)最稳妥）
处理日期字段时，EXTRACT(YEAR FROM ...) 比 YEAR(...) 更通用
MySQL 支持 YEAR(order_date)，但 PostgreSQL、Oracle、SQL Server 不认这个写法；EXTRACT(YEAR FROM order_date) 是标准 SQL，兼容性更好。SQLite 虽不支持 EXTRACT，但可用 strftime('%Y', order_date) 替代。
容易踩的坑是直接用 order_date::TEXT 或 TO_CHAR(order_date, 'YYYY') 分组——看似可行，但字符串比较可能隐式影响性能，且在某些数据库中无法利用日期索引。
- PostgreSQL / Oracle / BigQuery：用
EXTRACT(YEAR FROM order_date) - MySQL：可用
YEAR(order_date)，但为统一风格也建议用EXTRACT(YEAR FROM order_date) - SQL Server：用
DATEPART(YEAR, order_date) - SQLite：用
strftime('%Y', order_date)
当存在同一年多条记录排序相同时，ROW_NUMBER() 仍能保证唯一编号
比如同一日下单的多笔订单，ORDER BY order_date 会导致它们排序值相同。这时 ROW_NUMBER() 会按物理/扫描顺序“强行”赋予不同序号（非确定性，但一定不重复），而 RANK() 会让它们共享同一个排名，后续编号跳过相应位数。
如果你需要稳定结果（例如测试可重现），必须在 ORDER BY 中加入足够区分的二级排序，比如 ORDER BY order_date, id。
- 不加二级排序：编号结果依赖查询执行计划，可能每次运行不同
- 加
id或其他主键字段：确保排序唯一，编号完全确定 - 避免用
ORDER BY order_date, RANDOM()：虽能去重但丧失业务意义，且影响性能
性能敏感场景下，别在大表上对未索引字段做 PARTITION BY
PARTITION BY 本身不走索引，但数据库通常会先按分区键分组再排序。如果年份字段没索引，又恰好要查最近三年数据，优化器可能放弃索引扫描，转为全表排序——尤其当表超千万行时，延迟明显。
真实案例：某订单表用 created_at 字段计算年份，但没建函数索引，PARTITION BY EXTRACT(YEAR FROM created_at) 导致查询变慢 3 倍。
- MySQL 8.0+：可建函数索引
CREATE INDEX idx_year ON orders ((YEAR(created_at))) - PostgreSQL：建表达式索引
CREATE INDEX idx_orders_year ON orders (EXTRACT(YEAR FROM created_at)) - 更简单做法：冗余一个
order_year INT字段，写入时计算好并建普通索引
真正麻烦的不是语法，而是年份提取逻辑和排序依据是否覆盖了所有业务边界——比如跨年订单补录、时区转换导致的日期偏移、空值年份如何归类。这些细节不处理，编号看着对，导出后一核对就错。
