navicat的「解释」对窗口函数基本没用，因其默认仅执行explain select，不展开窗口内部排序、帧扫描及内存开销；mysql 8需用explain format=json或profiling+performance_schema手动验证真实性能。
navicat 本身不分析窗口函数性能，它只执行和展示 mysql 原生的 explain 结果；真正影响窗口函数快慢的是分区大小、排序字段是否走索引、帧范围是否可控——这些必须手动检查，不能依赖 navicat 界面里的“解释”按钮。
为什么 Navicat 的「解释」对窗口函数基本没用？
Navicat 点击 ⚡ 图标默认发送的是 EXPLAIN SELECT ...，而 MySQL 8 对含窗口函数的语句在 EXPLAIN 模式下不展开计算逻辑：它会把整个窗口表达式标记为 WINDOW 类型操作，但不显示内部排序开销、临时内存使用或帧扫描行数。你看到的 rows 常是全表预估值，Extra 里也不会出现 Using filesort 这类关键提示——因为排序确实发生了，只是被封装进 WINDOW 步骤里隐藏了。
- MySQL 8.0+ 的
EXPLAIN FORMAT=JSON才会暴露windowing字段，含sort_key、frame等细节，但 Navicat 不自动加这个参数 - 直接写
EXPLAIN ANALYZE会真实执行一次（含排序和临时表写入），可能触发磁盘溢出或锁等待，慎用于生产大表 - Navicat 的表格视图会折叠
EXPLAIN FORMAT=JSON的嵌套结构，关键字段如memory_used或sort_merge_passes需要手动展开 JSON 查看
怎么手动查窗口函数的真实开销？
绕过 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) ...，检查 JSON 输出中sort_key是否匹配key列显示的索引名；若sort_key是(created_at)但key为NULL，说明created_at单独无索引，排序必走 filesort
哪些窗口写法会悄悄拖垮性能？
窗口函数本身不慢，但常见写法会让优化器失控或触发不可控资源消耗：
-
PARTITION BY字段无索引 +ORDER BY字段也无索引 → MySQL 必须全表扫描后建临时内存/磁盘排序，rows显示不准，实际耗时飙升 - 帧范围写成
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING→ 每行都要扫完整个分区，无法流式计算，内存占用线性增长 - 在
WHERE条件里引用窗口别名（如WHERE rn = 1）→ MySQL 8.0.22+ 才支持，旧版会报错Unknown column 'rn' in 'where clause'，被迫改写为子查询，丧失窗口原生优化 - 用
LAG()/LEAD()且PARTITION BY组内行数超百万 → 函数内部需随机跳转，若未命中 buffer pool，I/O 毛刺明显
真正卡点往往不在语法对不对，而在分区边界是否与业务主键对齐、排序字段有没有覆盖索引、以及是否误以为 EXPLAIN 能反映窗口内部行为——它不能，得靠 FORMAT=JSON + performance_schema + 实际 profiling 三者交叉验证。
