SQL多窗口函数性能下降主因是重复扫描、排序叠加和内存激增；优化需减少重复排序、复用结果、控分区粒度、避隐式转换，并通过统一OVER子句、CTE预计算、精简定义及索引等手段实现。
SQL 中同时使用多个窗口函数时，性能下降往往不是因为函数本身复杂，而是执行计划重复扫描、排序开销叠加、内存占用激增导致的。关键优化思路是：减少重复排序、复用计算结果、控制分区粒度、避免隐式类型转换。
合并共用 PARTITION BY 和 ORDER BY 的窗口函数
多个窗口函数若使用完全相同的 PARTITION BY 和 ORDER BY 子句，数据库（如 PostgreSQL、SQL Server、Oracle）通常能自动复用排序结果；但 MySQL 8.0+ 才较好支持该优化，旧版本或某些场景下仍会分别排序。
- 显式统一写法：把
ROW_NUMBER()、RANK()、AVG() OVER(...)等放在同一SELECT中，且确保它们的OVER子句完全一致 - 避免“看似相同实则不同”：比如一个写
ORDER BY create_time，另一个写ORDER BY create_time ASC（虽等价，但部分引擎不识别为相同排序上下文） - 测试执行计划：用
EXPLAIN ANALYZE观察是否只出现一次 WindowAgg 或 Sort 节点
用 CTE 或子查询预计算高频窗口逻辑
当某组窗口计算（如按用户分组的累计金额、排名）被多个后续表达式依赖时，先在 CTE 中算出，再在主查询中引用，可避免重复计算和冗余字段传递。
- 例如：需同时用到
user_rank、user_percent_rank、user_cumsum，全部基于PARTITION BY user_id ORDER BY order_time，就应统一在 CTE 中产出这三列 - 注意 CTE 不是物化视图（除非用
MATERIALIZED显式声明），但多数现代引擎会对单次引用的 CT
E 进行内联优化；若多次引用，考虑临时表
- 避免在 CTE 中塞入无关字段——宽表会增加中间结果集大小，拖慢后续 JOIN 或过滤
精简窗口定义，避免过度分区与全表排序
窗口函数性能对 分区大小 敏感度远高于函数类型本身。一个百万行表按单列 country 分区，可能产生 200 个大分区；而按 (country, year) 可能生成上千个小分区，排序更轻量但调度开销上升。
- 优先使用高基数、业务语义明确的组合分区键，而非盲目加字段
- 若仅需全局统计（如
AVG(sales) OVER()），明确写空OVER()，不要写成OVER(PARTITION BY 1)或类似伪分区，防止引擎误判 - 对
ORDER BY字段建立索引——尤其当窗口含ROWS BETWEEN或需要稳定排序时，索引可避免额外排序节点
警惕数据类型与 NULL 处理引发的隐式开销
窗口函数内部对 NULL 的处理策略（如 ROW_NUMBER() 把 NULL 排最前/最后）、以及排序字段类型不匹配（如字符串字段未加 COLLATE），都可能导致引擎放弃索引、强制哈希排序或逐行比较。
- 显式控制 NULL 位置：用
ORDER BY col NULLS LAST（PostgreSQL/Oracle）或ORDER BY IFNULL(col, 'zzz')（MySQL）保持行为确定且利于索引利用 - 确保
PARTITION BY字段类型一致：比如关联表中一个是VARCHAR(50)，另一个是VARCHAR(100)，JOIN 后用于分区可能触发隐式转换 - 聚合类窗口（如
SUM() OVER(...)）在遇到大量 NULL 时，部分引擎会退化为逐行扫描而非增量累加，可提前用COALESCE(val, 0)预处理
