窗口函数慢主因是未走索引或数据量超预期，需检查EXPLAIN中type是否为ALL/index，确认PARTITION BY和ORDER BY字段是否建立匹配顺序的联合索引，并执行ANALYZE TABLE更新统计信息。
窗口函数本身不慢，慢在没走索引或数据量超预期
navicat 里执行带 row_number()、rank() 或 avg() over() 的 sql 慢，通常不是窗口函数语法的问题，而是底层数据扫描方式不合理。mysql（尤其是 8.0+）对窗口函数支持已较成熟，但优化器仍可能选错执行路径：比如该用索引排序却做了全表扫描，或 partition by 字段无索引导致临时表膨胀。
- 检查
EXPLAIN输出里的type：如果是ALL或index，说明没走有效索引 - 确认
PARTITION BY和ORDER BY字段是否联合建了索引（顺序必须匹配） - 避免在
OVER()子句里对字段做函数操作，如ORDER BY DATE(created_at)会失效索引 - 若只取前 N 行（如分页），务必加
LIMIT——否则 MySQL 可能先算完整个窗口再截断
Navicat 的“解释”功能容易掩盖真实瓶颈
在 Navicat 点击“解释”看到的执行计划，是图形化简略版，常隐藏关键信息。比如它不显示 Buffers 缓存命中率、Temp Table 是否使用磁盘、或窗口计算是否触发了 Using filesort 和 Using temporary。
- 直接在查询窗口运行：
EXPLAIN FORMAT=TRADITIONAL SELECT ... OVER(...) - 重点看
Extra列：出现Window function是正常；但若同时有Using temporary; Using filesort，说明分区/排序逻辑没被索引覆盖 - 对比加
LIMIT 100前后的rows和filtered：如果加 LIMIT 后rows不降，说明窗口计算未下推，全量数据已被载入内存
MySQL 8.0+ 窗口函数的几个硬限制
不是所有写法都能高效执行。以下情况即使有索引，MySQL 也可能放弃优化：
-
PARTITION BY字段类型和索引字段类型不一致（如索引是BIGINT，但查询中传入字符串'123'，触发隐式转换） - 使用了非确定性函数（如
NOW()、RAND()）在OVER()中，导致无法复用中间结果 - 嵌套窗口函数，例如
ROW_NUMBER() OVER(ORDER BY AVG(x) OVER(PARTITION BY y))，MySQL 不支持多层窗口嵌套 - 涉及 JSON 字段或全文索引列的
ORDER BY，基本无法利用索引加速排序
真正有效的提速动作就三件
别在 Navicat 里调参数或换显示模式，问题不在客户端。聚焦数据库侧可验证的改动：
- 给
PARTITION BY a, ORDER BY b建联合索引：CREATE INDEX idx_a_b ON t(a, b)（注意顺序） - 把
WHERE条件尽量写在窗口函数外层，而不是塞进子查询里——MySQL 对子查询内窗口的支持更弱 - 如果只是分页，用
OFFSET+LIMIT配合覆盖索引，比ROW_NUMBER() = ?更快（尤其偏移量大时）
最常被忽略的是：改完索引后没跑 ANALYZE TABLE t，统计信息过期会让优化器继续“瞎选”执行路径——这一步在数据批量更新后必须补上。
