不加order by时，sum() over()每行结果相同，因默认对整个分区静态求和；加order by后才实现逐行累计，且需注意排序方向、重复值处理、索引优化及帧定义。
不加ORDER BY时，SUM() OVER()每行结果都一样
窗口函数默认不启用“逐行推进”逻辑。没写ORDER BY，SUM(amount) OVER (PARTITION BY user_id)就对整个分区静态求和，每行返回的都是该用户全部金额总和。这不是你想要的“截至当前行的累计值”，只是重复打印同一个数字。
常见错误现象：ROW_NUMBER() OVER (PARTITION BY user_id)每次执行序号乱跳——因为数据库按物理存储顺序排，这个顺序不可控、不可重现。
- PostgreSQL 会直接报错；MySQL 8.0+ 和 SQL Server 虽允许运行，但结果无保证
- 如果真不需要排序（比如只统计行数），用
COUNT(*) OVER (PARTITION BY user_id)更安全 - 业务上若允许时间字段重复（如毫秒级精度不足），必须补唯一键兜底：
ORDER BY created_at, id
加了ORDER BY后，累计方向和起点全变了
ORDER BY不是单纯排序，它定义了“当前行”在窗口里的位置锚点。一旦加上，数据库就必须按指定顺序逐行计算，默认帧是ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW——也就是从分区第一行加到当前行。
但方向由ASC/DESC决定：SUM(sales) OVER (ORDER BY date ASC)是正向累计（历史总和），而SUM(sales) OVER (ORDER BY date DESC)是反向累计（剩余未完成量）。注意：UNBOUNDED PRECEDING始终指向排序后序列的起点，即最大值所在行。
- 漏写
DESC会导致“以为降序，实为升序”，数据看起来全反了 -
ORDER BY status, updated_at DESC中，status仍是升序，不会被后面的DESC影响 - 显式写全方向更安全：
ORDER BY status ASC, updated_at DESC
ROWS和RANGE在ORDER BY有重复值时行为完全不同
排序字段有重复值（比如多笔订单同一天），ROWS和RANGE的差异立刻暴露：ROWS严格按物理行序计数，RANGE按排序值逻辑分组。
例如某天有3条记录：SUM(sales) OVER (ORDER BY sale_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)逐条累加；换成RANGE后，第1行就等于当天全部3条之和——因为所有同日期记录被归入同一组。
-
LAG()、LEAD()、FIRST_VALUE()必须用ROWS，RANGE下“上一行”可能不存在或指向同组任意行 -
LAST_VALUE(x) OVER (ORDER BY ts)默认只返回当前行值，因为默认帧是RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，不是整个分区 - 要取分区末值，必须显式写：
LAST_VALUE(x) OVER (ORDER BY ts ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
ORDER BY字段没索引，性能会断崖式下跌
带ORDER BY的窗口函数（尤其是ROWS BETWEEN类）必须先完成全分区内部排序，再逐行划窗。若缺少对应索引，就会触发磁盘级filesort，I/O 成瓶颈。
复合索引必须严格按PARTITION BY字段在前、ORDER BY字段紧随其后的顺序建立，例如(user_id, created_at)；(created_at, user_id)无效。用表达式排序（如ORDER BY DATE(created_at)）会让普通索引失效。
- 检查执行计划：
EXPLAIN中Extra出现Using filesort就是危险信号 - MySQL 8.0+ 才支持函数索引，旧版本只能冗余存
date_only列并建索引 - 高频查询可考虑预物化：用
INSERT SELECT定期写入带累计字段的宽表
