MySQL执行计划不显示窗口函数独立节点，其计算隐式融入查询流程，性能关键在于索引能否复用排序，分区、排序、计算三步不可逆，需结合profile和optimizer_trace诊断瓶颈。
MySQL 执行计划里根本看不到窗口函数的独立执行节点
MySQL 的 EXPLAIN（包括 EXPLAIN FORMAT=TREE）不把窗口函数当作一个可拆解的“算子”来展示。它不会像 GROUP BY 或 JOIN 那样生成明确的物化、排序、聚合等阶段标识。窗口函数的计算被隐式揉进整个查询流程里，尤其是依赖于 ORDER BY 和分区逻辑的部分——你看到的往往是排序操作（Using filesort）或临时表（Using temporary），但不会标出“这里在算 ROW_NUMBER()”。
真正影响性能的关键点是：窗口函数是否能复用已有的索引排序，还是被迫触发额外排序。
- 如果
OVER (ORDER BY col)的列有合适索引（且无反向、无表达式、无函数包裹），MySQL 5.7+ / 8.0 可能跳过Using filesort - 如果用了
PARTITION BY a ORDER BY b，而索引是(a, b)，大概率走索引；但如果是(b, a)，就无法利用，强制排序 -
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这类累积型窗口比ROW_NUMBER()更吃内存，因为需要维护运行状态，容易触发Using temporary
窗口函数实际执行分三步：分区 → 排序 → 计算
虽然 EXPLAIN 不显式分步，但 MySQL 内部确实是按这个顺序干活的。顺序不可逆，也不能跳过——哪怕你只写 ROW_NUMBER() OVER ()（无 PARTITION BY 和 ORDER BY），它仍会把全表当做一个分区，并按主键隐式排序（除非优化器选择哈希处理，但 8.0 默认倾向排序）。
- 没写
PARTITION BY？整张表就是一个分区，数据量大时极易内存溢出 - 没写
ORDER BY？MySQL 8.0 会报错：This function requires an ORDER BY clause（除COUNT(*) OVER ()等极少数例外） -
RANGE窗口帧（如RANGE BETWEEN ...）比ROWS更慢，因为要按值比较而非行偏移，还可能触发重复扫描
如何判断窗口函数是否成了性能瓶颈
别只盯着 EXPLAIN 输出，重点看执行时的真实行为：
- 查
SHOW PROFILE或performance_schema.events_statements_history_long，看Sorting result和Creating sort index耗时占比 - 观察
Handler_read_*状态：如果Handler_read_next远高于Handler_read_first，说明在反复扫描排序后的结果集——这是窗口函数遍历帧的典型特征 - 开
optimizer_trace，搜"window_function"字段，能看到优化器是否下推了排序、是否选择了物化路径 - 用
SELECT ... WINDOW w AS (PARTITION BY x ORDER BY y)定义命名窗口，方便复用；但注意：多个引用同一命名窗口的函数，仍会共用一套排序结果，不会重复排
容易被忽略的兼容性陷阱
MySQL 8.0 是第一个完整支持窗口函数的 GA 版本，但很多细节在小版本间有变化：
- 8.0.0–8.0.16 对
LAG()/LEAD()的默认offset处理不一致，某些版本要求显式写LAG(col, 1)，否则报错 -
NTILE(n)在数据行数不能被n整除时，前几组会多一行——这个行为是标准定义，但业务代码若假设“每组等长”，就会出错 - JSON 函数（如
JSON_EXTRACT）不能直接用于ORDER BY子句中驱动窗口排序，会报Invalid use of NULL或隐式转换失败，必须先用CAST(... AS SIGNED)显式转类型 - 从 8.0.32 开始，
WINDOW子句支持在 CTE 中定义，但外层查询不能跨 CTE 引用该命名窗口——作用域限制很严格
窗口函数不是“语法糖”，它是带状态的逐行计算过程。执行计划里看不见它，不等于它不消耗资源；最省事的写法，往往在运行时最费劲。
