窗口函数执行慢需先确认是否真慢：应用层超时≠mysql慢查询，应以slow_query_log为准；explain中type=all或using temporary表明索引缺失或类型不一致；partition by和order by字段须建合适索引；避免函数操作导致索引失效；rows_examined过大时应缩小分区粒度、加where过滤；优先用row_number()而非rank()；子查询套窗口函数多可改写为join优化。
窗口函数执行慢，先看是不是真慢
很多“窗口函数慢”其实是误判：比如应用层超时设成800ms，但SQL实际执行900ms，就报慢；而MySQL自己并不认为它慢——因为没进慢查询日志（long_query_time默认是2秒）。真正要盯的，是那些被slow_query_log记录下来的窗口函数查询。否则优化方向容易跑偏。
EXPLAIN里type=ALL或Using temporary？说明窗口函数没走索引
MySQL 8.0+对窗口函数的支持虽好，但不等于自动优化。执行EXPLAIN后如果出现：
– type = ALL：说明ORDER BY或PARTITION BY字段没索引，被迫全表扫描
– Extra = Using temporary：大概率是ORDER BY字段未被索引覆盖，或PARTITION BY列类型不一致（比如一边VARCHAR一边CHAR），触发隐式转换
– key = NULL：哪怕写了ORDER BY create_time，只要create_time没索引，照样失效
- 必须给
PARTITION BY字段建索引（尤其是高基数字段，如user_id） -
ORDER BY字段必须单独有索引，或作为复合索引最右前缀（如INDEX(user_id, create_time)支持PARTITION BY user_id ORDER BY create_time） - 避免在窗口函数中对字段做函数操作：
ROW_NUMBER() OVER (ORDER BY DATE(create_time))→ 索引失效，改用ORDER BY create_time
ROWS_EXAMINED远大于结果行数？说明窗口计算范围过大
窗口函数性能瓶颈常不在“计算本身”，而在“需要读多少行”。比如：SELECT *, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) rn FROM employees;
如果dept_id只有5个值，但员工总数200万，那每个分区都要排序全部数据——Rows_examined可能高达千万级。
- 优先缩小
PARTITION BY粒度：用更细的分组字段（如dept_id, team_id）替代粗粒度字段 - 加WHERE提前过滤：不要等窗口函数执行完再
LIMIT，而是先限定时间范围或状态：WHERE status = 'active' AND hire_date >= '2023-01-01' - 避免
RANK()/DENSE_RANK()在大数据量下使用：它们需全局比较，比ROW_NUMBER()更重；能用ROW_NUMBER()就别用前者
子查询套窗口函数？90%可改写为JOIN + 窗口
常见写法：SELECT * FROM orders WHERE id IN (SELECT id FROM (SELECT id, ROW_NUMBER() OVER (ORDER BY amount DESC) rn FROM orders) t WHERE rn <br>这种嵌套会让MySQL先物化内层结果集，再JOIN，极易OOM或触发磁盘临时表。
- 直接展开：用CTE或派生表把窗口逻辑前置，再JOIN原表
- 更稳写法：
SELECT o.* FROM orders o JOIN (SELECT id FROM (SELECT id, ROW_NUMBER() OVER (ORDER BY amount DESC) rn FROM orders WHERE status = 'paid') t WHERE rn - 注意：外层
SELECT *会拖慢速度，只取必要字段；若需关联用户信息，用LEFT JOIN users u ON o.user_id = u.id，别在窗口内JOIN
窗口函数不是银弹，它解决的是“按组排序/排名/累计”这类问题，但代价是内存和扫描量。真正卡住的，往往不是函数本身，而是没约束的分区、没索引的排序字段，或者写在子查询里的反模式用法。动手前，先看EXPLAIN和Rows_examined，比调参管用十倍。
