窗口函数可将n次表扫描压缩为1次，但需正确使用over子句、搭配合适索引；row_number()必须带over，且应含partition by和order by；sum()等聚合函数推荐用rows而非range帧定义；排名函数语义不同，须按业务选型；结果不可用于where/having；性能瓶颈在索引缺失而非语法本身。
直接结论：用窗口函数替代多层嵌套子查询或自连接，能将一次复杂聚合从 N 次表扫描压到 1 次扫描，前提是 OVER 子句写对、索引跟上。
ROW_NUMBER() 必须带 OVER，否则 MySQL 8.0 直接报 ERROR 1064
这不是兼容性警告，是语法硬性要求。MySQL 解析器看到 ROW_NUMBER() 就会检查后面有没有 OVER；没写就拒绝执行，连优化器都不触发。
-
ROW_NUMBER() OVER ()合法但危险：全表无序编号，每次执行顺序可能不同，业务不可控 - 真正可用的写法必须含
PARTITION BY和ORDER BY，例如：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) - 如果只是想全局编号且接受不确定性，至少加个主键字段保序：
ROW_NUMBER() OVER (ORDER BY id)
SUM() OVER 代替自连接累计求和，ROWS 比 RANGE 更稳更快
累计销售额、滚动平均这类场景，传统写法常靠关联子查询或用户变量，结果难复现、性能差。窗口函数一行解决，但关键在帧定义方式。
-
SUM(sales) OVER (ORDER BY sale_date ROWS UNBOUNDED PRECEDING)：按物理行偏移计算，稳定、可预期、能走索引 -
SUM(sales) OVER (ORDER BY sale_date RANGE UNBOUNDED PRECEDING)：按值范围匹配，遇到重复sale_date会把同一天所有行都算进当前窗口，结果膨胀 - 安全写法建议补唯一字段防重复：
SUM(sales) OVER (ORDER BY sale_date, id ROWS UNBOUNDED PRECEDING)
排名类函数选错会导致业务逻辑出错
ROW_NUMBER()、RANK()、DENSE_RANK() 行为差异不是风格问题，是语义级区别，直接影响“第几名”的业务含义。
- 相同值时：
ROW_NUMBER()强制递增（1,2,3），适合流水号；RANK()并列跳号（1,1,3），适合榜单；DENSE_RANK()并列不跳号（1,1,2），适合考试名次 - 窗口函数结果不能出现在
WHERE或HAVING中——它们在 WHERE 之后执行。要过滤排名前 3，必须套一层子查询或 CTE - 确认 MySQL 版本：执行
SELECT VERSION();，低于 8.0 会报ERROR 1305 (42000): FUNCTION does not exist
窗口函数性能卡点不在语法，在索引与执行计划
窗口函数本身不慢，慢的是没索引支撑的 PARTITION BY 和 ORDER BY 字段。EXPLAIN 看到 Using temporary; Using filesort 就说明掉坑里了。
-
PARTITION BY dept_id ORDER BY salary DESC要求联合索引为(dept_id, salary)，且方向一致（DESC 需显式声明） - 避免在
ORDER BY中用函数，如ORDER BY DATE(create_time)—— 改用生成列 + 索引 - CTE 里引用窗口函数不等于自动物化；非递归 CTE 默认被内联展开，执行计划仍取决于主查询结构
最易被忽略的点：窗口函数的计算边界由 PARTITION BY 和 ORDER BY 共同定义，缺一不可；而帧子句（ROWS / RANGE）一旦写错，结果偏差无法通过肉眼识别，只能靠小数据集验证逻辑。
