窗口函数排序不走索引时会强制磁盘排序，需为PARTITION BY a ORDER BY b创建联合索引(a,b)，表达式排序需函数索引，字符串排序注意校对规则，共用相同OVER子句可复用排序，避免混用不同排序方向，WHERE提前过滤更高效，ROWS BETWEEN可替代默认RANGE避免隐式排序。
窗口函数排序不走索引时会强制磁盘排序
窗口函数的 ORDER BY 子句不是可选装饰，而是实际触发排序操作的开关。没索引支撑时，SQL Server 或 MySQL 8.0+ 会把整个分区数据拉进内存排序；一旦超出 sort_buffer_size（MySQL）或 max server memory（SQL Server），就溢出到 tempdb 或磁盘临时表——这时你会在执行计划里看到 Sort 节点带 Warning: Operator used tempdb to spill data。
- 必须为
PARTITION BY a ORDER BY b创建联合索引(a, b)，顺序不能颠倒 - 若排序字段是表达式（如
ORDER BY YEAR(order_time)），需建函数索引（MySQL 8.0+ 支持，SQL Server 需计算列+索引） - 字符串字段排序要留意 collation，
utf8mb4_0900_as_cs和utf8mb4_general_ci对比结果不同，可能让优化器放弃索引
多个窗口函数共用相同 OVER 子句才能复用排序结果
写 ROW_NUMBER() OVER(PARTITION BY dept_id ORDER BY salary DESC), AVG(salary) OVER(PARTITION BY dept_id ORDER BY salary DESC) 是安全的——现代引擎（SQL Server 2016+、PostgreSQL 13+、MySQL 8.0.22+）会识别并复用一次排序。但写成 ORDER BY salary DESC 和 ORDER BY salary DESC ASC（语法合法但语义冗余），部分版本仍会分别排序。
- 检查执行计划：只应出现一个
Sort或Window Spool节点，而不是每个函数都带一个 - 避免在同一个 SELECT 中混用不同排序方向，比如一个
ORDER BY create_time DESC，另一个ORDER BY create_time ASC - MySQL 5.7 不支持窗口函数，强行使用会报错
FUNCTION ROW_NUMBER does not exist
WHERE 提前过滤比在 CTE 里套窗口更省资源
窗口函数无法下推过滤条件。写 WITH ranked AS (SELECT *, ROW_NUMBER() OVER(...) rn FROM orders) SELECT * FROM ranked WHERE rn ，引擎仍会先算完整个表的 row number，再裁剪——如果原始表有千万行，而你只关心最近 7 天的 2 万单，这就白干了 99.8% 的排序工作。
- 永远优先把
WHERE放在窗口之前：SELECT *, ROW_NUMBER() OVER(...) FROM orders WHERE order_time >= '2026-07-14' - CTE 不是物化视图，多数引擎会内联展开；只有当同一结果被多次引用且数据稳定时，才考虑用临时表缓存
- 如果业务逻辑要求“每个用户最近 3 笔订单”，别用
PARTITION BY user_id ORDER BY order_time DESC然后全表扫——改用WHERE (user_id, order_time) IN (SELECT user_id, MAX(order_time) FROM ...)这类半连接，反而更快
ROWS BETWEEN 能关掉默认的 RANGE 模式避免隐式排序
默认的窗口帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，它要求按 ORDER BY 列做逻辑排序（含重复值归组），比 ROWS BETWEEN 更重。尤其当 ORDER BY 字段存在大量重复值（如状态码、分类 ID），RANGE 模式会额外做等值分组扫描。
- 明确写
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW可跳过 RANGE 分组逻辑 - 累计求和、移动平均这类场景，
ROWS语义更准也更快；只有需要“同分数同排名”才用RANGE - MySQL 8.0 对
RANGE支持有限，遇到RANGE+ 高重复值容易退化成文件排序
真正卡住性能的，往往不是窗口函数本身，而是你没意识到 OVER 里的 ORDER BY 已经在默默申请内存、争抢 tempdb、等待 latch——它不像 GROUP BY 那样显眼报错，但慢得无声无息。
