无ORDER BY的ROW_NUMBER()结果不可预测，数据库按物理或扫描顺序编号；累计求和必须用ORDER BY明确逻辑顺序，否则非逐行累加；重复排序键导致并列累计值相同。
没有 ORDER BY 的 ROW_NUMBER() 会怎样
它不报错，但结果不可预测——数据库可能按物理存储顺序、扫描顺序或优化器临时决定的顺序给行编号，同一张表反复执行可能得到不同序号。这不是 bug，是 SQL 标准允许的行为：窗口函数没指定 ORDER BY，就等于没定义排序依据。
常见错误现象：ROW_NUMBER() OVER (PARTITION BY user_id) 用于“取每个用户最新一条记录”，结果随机挑中某条，上线后数据对不上。
- 真正需要“最新”，必须显式用时间字段排序：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) - 如果业务上真不需要排序（比如只是打个无意义序号），请用
GENERATE_SERIES()（PostgreSQL）或ROWNUM（Oracle）等更明确的机制，别依赖无序窗口函数 - MySQL 8.0+ 和 SQL Server 对无
ORDER BY的窗口函数警告级别不同，但行为一致：不保证稳定
全量累计求和必须加 ORDER BY 吗
必须。累计汇总本质是“按某个逻辑顺序逐行叠加”，这个顺序必须由 ORDER BY 明确声明，否则数据库无法知道“哪一行该加在哪一行之后”。即使你只写 SUM(value) OVER ()，也等价于 SUM(value) OVER (ORDER BY (SELECT NULL))，而多数引擎会拒绝这种写法或返回全表总和（即非累计）。
使用场景：按日期逐日累加销售额、按流水 ID 累计用户积分。
- 正确写法：
SUM(amount) OVER (ORDER BY order_date, order_id)—— 多字段排序防并列时结果漂移 - 别用
ORDER BY id代替业务时间，ID 递增不等于业务发生顺序（比如批量补录、分库 ID 冲突） - PostgreSQL 允许
ORDER BY ctid做物理顺序累计，但仅限调试，不可用于生产逻辑
ORDER BY 字段有重复值时累计值怎么算
所有相同排序键的行会得到相同的累计值（即“并列处理”）。例如三行 order_date = '2024-01-01'，它们的 SUM(x) OVER (ORDER BY order_date) 都等于这三行的和，而不是逐行递增。
性能影响：重复值越多，窗口帧越难优化，某些引擎（如 Hive）会退化成全表扫描。
- 想避免并列？补一个唯一字段：如
ORDER BY order_date, order_id或ORDER BY order_date, ROWID - 想保留并列语义（比如按天统计，当天所有记录共享当日累计）？那就接受它，但需在业务层说明“这是按天聚合的累计，非实时流式累计”
- SQL Server 中可用
ROWS UNBOUNDED PRECEDING显式控制帧范围，但依然不能绕过ORDER BY的必要性
替代方案：不用窗口函数也能做全量累计吗
能，但代价高。自连接、子查询、变量（MySQL）都可实现，但几乎都会触发 O(n²) 扫描或失去并行能力。
典型错误：SELECT a.date, (SELECT SUM(b.val) FROM t b WHERE b.date —— 表越大越慢，且无法下推过滤条件。
- PostgreSQL 可用
LATERAL JOIN+ 索引优化，但代码复杂度陡增 - MySQL 5.7 用用户变量看似简洁：
@sum := @sum + val，但执行计划不稳定，多线程或优化器改写可能让变量失效 - 真正要兼顾可读、性能、可维护，还是老实用带
ORDER BY的窗口函数——它就是为这事设计的
容易被忽略的一点：累计汇总的“起点”不是第一行，而是 ORDER BY 排序后的第一行。如果排序字段有 NULL，不同数据库默认把 NULL 当最大还是最小处理（如 PostgreSQL 默认 NULLS LAST），会影响累计起始位置，上线前务必验证 NULL 数据的排序行为。
