选row_number()、rank()或dense_rank()取决于并列处理需求：row_number()强制连续编号；rank()同分同号但跳名次；dense_rank()同分同号且不跳号。
ROW_NUMBER()、RANK()、DENSE_RANK() 选哪个？看并列怎么处理
三者都用于排名，但对相同值的处理逻辑完全不同：ROW_NUMBER() 强制连续编号，同分也不同号；RANK() 同分同号，但会跳过后续名次；DENSE_RANK() 同分同号，后续不跳号。
比如成绩为 95, 95, 90, 85：
-
ROW_NUMBER()→1, 2, 3, 4 -
RANK()→1, 1, 3, 4 -
DENSE_RANK()→1, 1, 2, 3
实际选型取决于业务规则：做“唯一序号”用 ROW_NUMBER()；做“榜单排名”且允许并列时，RANK() 更符合大众认知（如奥运奖牌榜）；做“梯队划分”或分桶时，DENSE_RANK() 更利于后续分组统计。
OVER() 里不写 ORDER BY 就会乱序
这是最常踩的坑：ROW_NUMBER()、RANK() 等排名函数必须依赖明确的排序依据。如果 OVER() 中没写 ORDER BY，MySQL 会按不确定的物理存储顺序编号，结果每次执行都可能不同。
错误写法：ROW_NUMBER() OVER () —— 即使外层有 ORDER BY score DESC，窗口计算早已完成，无法影响编号逻辑。
正确写法必须显式声明：ROW_NUMBER() OVER (ORDER BY score DESC) 或带分区：ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC)。
注意：ORDER BY 在 OVER() 内部定义的是窗口内排序，和最终查询的 ORDER BY 是两回事，不可互相替代。
SUM()、AVG() 等聚合类窗口函数默认算累计值
SUM(col) OVER (PARTITION BY x ORDER BY y) 默认行为是 “从分区第一行到当前行” 求和，也就是累计和。这由隐式窗口帧 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 决定。
如果想改成全分区总和，得显式写：SUM(col) OVER (PARTITION BY x RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) 或更简洁地：SUM(col) OVER (PARTITION BY x)（此时无 ORDER BY，窗口帧自动扩展为整分区）。
性能提示：加 ORDER BY 会触发排序开销；不加则快，但无法支持累计、移动平均等依赖顺序的计算。
LAG()/LEAD() 取前后行值时，默认偏移量是 1
LAG(col) 相当于 LAG(col, 1)，取上一行的 col 值；LEAD(col, 2) 取下两行。第三个参数是默认值，当越界时返回它（比如首行调用 LAG()，若没设默认值就返回 NULL）。
常见用途：
- 计算环比：
amount - LAG(amount) OVER (ORDER BY date) - 判断是否首单：
LAG(order_id) OVER (PARTITION BY user_id ORDER BY create_time) IS NULL - 补缺失值：
COALESCE(current_value, LAG(current_value) OVER (...))
注意：LAG() 和 LEAD() 必须配合 ORDER BY 使用，否则行为不可预测；且它们只作用于当前窗口内，跨分区不生效。
窗口函数真正容易被忽略的点不在语法本身，而在执行时机——它发生在 SELECT 投影之后、最终 ORDER BY 之前。这意味着你看到的“排序后结果”，其实早就在窗口计算阶段固化了顺序逻辑。任何想靠外层排序“修正”窗口输出的行为，都是徒劳的。
