Navicat 16 的「解释」按钮对窗口函数无效，仅执行普通 EXPLAIN；必须手动用 EXPLAIN FORMAT=JSON 查看 windowing 字段中的 sort_key、frame、memory_used 等真实开销指标，避免使用 EXPLAIN ANALYZE。
Navicat 16 的「解释」按钮对窗口函数基本无效
点击 ⚡ 图标执行的只是 EXPLAIN SELECT，MySQL 8+ 在该模式下会把整个 OVER() 表达式压缩为一个 WINDOW 类型节点，不展开内部排序、帧扫描行数、临时内存分配等关键细节。你看到的 rows 常是全表预估，Extra 里也不会出现 Using filesort —— 尽管排序确实发生了，只是被封装隐藏了。
必须手动用 EXPLAIN FORMAT=JSON 查看 windowing 字段
Navicat 16 不自动加 FORMAT=JSON 参数，但它是唯一能暴露窗口真实开销的格式。在查询编辑器中直接运行：
EXPLAIN FORMAT=JSON SELECT user_id, order_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders;
然后在 Navicat 的执行计划面板里点开 JSON 结构，重点找：
- windowing 节点下的 sort_key：是否匹配你期望的索引字段
- frame 描述：比如 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 是否可控
- memory_used 和 sort_merge_passes：这两个值高说明内存不足、被迫落盘排序
别信 EXPLAIN ANALYZE，它会真实执行并可能卡住
EXPLAIN ANALYZE 对含窗口函数的大表极其危险——它真跑一次，触发完整排序+临时表写入，容易导致磁盘溢出或锁等待。只在小表（
- 先开 profiling：
SET profiling = 1; - 再执行你的窗口查询
- 查耗时分布：
SHOW PROFILE FOR QUERY N;，重点关注Creating sort index和Sending data阶段 - 查临时表使用：
SELECT * FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%OVER(%';，看TEMP_TABLES_INTERNAL和MEMORY_USED
分区大小和排序字段索引才是性能瓶颈所在
窗口函数快不快，跟 Navicat 无关，只取决于三件事：
- PARTITION BY 字段的基数：如果每组只有 2–3 行，开窗几乎无开销；如果某 user_id 占全表 70% 行，那这个分区就是热点
- ORDER BY 字段是否有可用索引：比如 ORDER BY created_at DESC，但表上只有 (user_id) 单列索引，sort_key 就会显示 (created_at) 而 key 为 NULL，说明必走 filesort
- 帧范围是否显式限制：用 ROWS BETWEEN 10 PRECEDING AND CURRENT ROW 比默认的 RANGE UNBOUNDED 更可控，也更容易命中索引
真正要调优，得回到表结构和索引设计上，Navicat 只是帮你看见问题的镜子，不是解药。
