navicat 的「解释」按钮对窗口函数无效，因其默认不支持 explain format=json，无法显示窗口内部排序、帧扫描及内存使用细节；需手动执行 explain format=json 或结合 profiling、performance_schema 等诊断语句分析真实开销。
Navicat 的「解释」按钮对窗口函数完全无效
点击 ⚡ 图标执行的 EXPLAIN SELECT 在 MySQL 8+ 中只会把整个窗口表达式标记为 WINDOW 类型，不展开排序、帧扫描或内存使用细节。你看到的 rows 是全表估算值，Extra 字段里也不会出现 Using filesort——但排序确实发生了，只是被封装隐藏了。
根本原因：MySQL 原生的普通 EXPLAIN 不解析窗口内部逻辑；只有 EXPLAIN FORMAT=JSON 才带 windowing 字段，含 sort_key、frame、memory_used 等关键信息。而 Navicat 16.1 默认不加这个参数，也不支持手动切换格式。
必须绕过 Navicat 界面，手写诊断语句
在 Navicat 查询编辑器中直接运行以下语句，才能拿到真实开销：
- 开启 profiling（仅限调试环境）：
SET profiling = 1;，再执行你的窗口查询，然后SHOW PROFILES;找到 Query ID，最后SHOW PROFILE FOR QUERY N;——重点看Sending data和Creating sort index阶段耗时 - 查临时表和内存使用：
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%OVER(%';，关注TEMP_TABLES_INTERNAL和MEMORY_USED - 验证索引是否生效：
EXPLAIN FORMAT=JSON SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) FROM orders;，检查 JSON 输出中sort_key是否等于(created_at)，且key字段是否非NULL
分区大小、排序字段、帧范围才是性能瓶颈所在
窗口函数快不快，和 OVER 子句里这三个要素强相关：
-
PARTITION BY分区太大（比如单个分区上万行），会导致排序内存溢出，触发磁盘临时表 —— 查Created_tmp_disk_tables可确认 -
ORDER BY字段没索引，或用了函数（如YEAR(created_at)），sort_key就会失配，强制filesort -
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这类无界帧比ROWS BETWEEN 10 PRECEDING AND 10 FOLLOWING消耗高得多，尤其在大分区下
这些点 Navicat 无法自动提示，必须人工比对 DDL、索引定义和窗口语义。
别信视图包装层，先展开再分析
如果窗口函数藏在视图里，EXPLAIN SELECT * FROM my_analytic_view 返回的完全是假数据。MySQL 对视图默认用 TEMPTABLE 算法物化，EXPLAIN 根本不展示物化开销。
正确做法：
- 右键视图 →「对象信息」→「DDL」标签页，复制
AS后面的原始SELECT - 替换掉所有参数占位符（如
WHERE dt = ?→WHERE dt = '2026-09-01'），否则key_len和possible_keys全失真 - 嵌套视图要逐层展开，直到所有
FROM都指向基础表为止
最常被忽略的一点：窗口函数本身不阻塞索引，但外层 ORDER BY 或 GROUP BY 若没覆盖索引，Extra 里照样冒出 Using temporary; Using filesort——而 Navicat 的图形界面根本不会高亮这条警告。
