MySQL 8.0 支持 WINDOW 子句，但仅为命名窗口定义的语法糖，不提供计算复用或结果缓存；所有共用同一 WINDOW 名称的函数仍独立执行完整排序与分组扫描，性能与重复书写 OVER 子句完全等价。
MySQL 8.0 确实支持 WINDOW 子句，但仅限于命名窗口定义，不能动态复用计算逻辑
MySQL 8.0 引入了 WINDOW 子句，但它只是语法糖，用于给窗口定义起别名，**不提供表达式复用或计算结果缓存能力**。你不能像在某些分析型数据库（如 ClickHouse、Doris）中那样“定义一次窗口，多次引用其排序/分区结果并自动复用中间状态”。所有窗口函数仍各自独立执行完整计算。
WINDOW 子句怎么写？哪些地方能用它？
只能用在 SELECT 列表中，且必须出现在所有窗口函数之前；它不改变执行计划，只避免重复写 PARTITION BY 和 ORDER BY。
-
WINDOW w AS (PARTITION BY user_id ORDER BY created_at)是合法定义 - 后续可写
ROW_NUMBER() OVER w、RANK() OVER w、AVG(score) OVER w - 但
AVG(score) OVER w和SUM(score) OVER w仍是两个独立的窗口扫描，不会共享排序结果或分组哈希表 - 不能在
WHERE、GROUP BY或子查询中引用w
为什么看起来“复用”了，实际性能没提升？
MySQL 的窗口函数实现基于临时表 + 一次全量排序（对每个窗口定义），即使多个函数共用同一个 WINDOW 名称，优化器也不会合并它们的执行路径。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 执行
EXPLAIN FORMAT=TREE可见：每个窗口函数对应一个独立的window function节点，哪怕都用OVER w - 如果写成
ROW_NUMBER() OVER (PARTITION BY a ORDER BY b), RANK() OVER (PARTITION BY a ORDER BY b)，和用WINDOW w AS (...)在性能上完全等价 - 真正影响性能的是窗口定义本身：
PARTITION BY字段是否走索引、ORDER BY是否能利用索引避免 filesort
想减少重复计算？只能靠业务层或物化中间结果
MySQL 8.0 没有窗口计算缓存机制，若需真正复用（比如先算排序序号，再基于该序号做条件过滤），得手动拆解：
- 用 CTE 先生成带序号的结果：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (PARTITION BY x ORDER BY y) rn FROM t) - 再在外部查询中复用
rn：SELECT * FROM ranked WHERE rn = 1或JOIN自身 - 对高频访问场景，考虑加覆盖索引：
INDEX(x, y)能加速PARTITION BY x ORDER BY y类窗口 - 注意：CTE 在 MySQL 8.0 中默认是 non-materialized（除非被引用多次或含不确定性函数），所以
ranked还是会执行一次，但至少避免了重复写窗口定义
真正容易被忽略的是：很多人以为 WINDOW w AS (...) 能让多个函数共享一次排序输出，其实它连内存排序结果都不复用——每个函数都重新跑一遍 sort + partition 扫描。要压性能，得从索引和数据分布下手，不是靠语法缩写。
