MySQL 8.0 窗口函数在处理排名、累计计算场景时，执行机制上优于关联子查询，因为它避免了对同一表的重复扫描。但具体性能提升幅度取决于数据量、索引覆盖情况以及查询复杂度，公开资料中没有看到可靠的量化数据适用于所有场景。
先说结论：窗口函数通过单次扫描完成计算，通常比 correlated subquery 更少消耗 I/O 和 CPU，但需确认 MySQL 版本不低于 8.0。
- 适合：排名计算、移动平均、累计求和、 gaps-and-islands 问题
- 重点看：EXPLAIN 输出中的 Rows_examined 和 Extra 字段
- 别忽略：窗口函数可能增加内存临时表使用，大数据量需监控 sort buffer
命令速用版
以下对比展示相同逻辑下子查询与窗口函数的写法差异，窗口函数写法更简洁且通常执行计划更优。
子查询写法（旧方案）：
SELECT a.id, a.val, (SELECT SUM(b.val) FROM t b WHERE b.id <= a.id) AS running_sum FROM t a;
窗口函数写法（新方案）：
SELECT id, val, SUM(val) OVER (ORDER BY id) AS running_sum FROM t;
为什么会这样
窗口函数允许在一次表扫描中完成聚合计算，而关联子查询往往需要对每一行执行一次子查询。
关联子查询在执行时，外部表的每一行都可能触发内部表的独立扫描或索引查找，导致时间复杂度接近 O(N^2)。窗口函数利用 OVER 子句定义窗口帧，优化器可以将计算逻辑合并到单次扫描流程中，减少重复的数据读取和上下文切换。但窗口函数需要在内存中维护窗口状态，如果 ORDER BY 字段无索引或数据量极大，可能触发磁盘临时表。
分步处理
1. 确认版本：执行 SELECT VERSION(); 确保版本号为 8.0.1 或更高，窗口函数在 8.0 之前不可用。
2. 重写查询：将原有的自连接或 correlated subquery 逻辑转换为 ROW_NUMBER()、RANK()、SUM() OVER 等语法。
3. 检查索引：确保 OVER 子句中 ORDER BY 和 PARTITION BY 涉及的字段有索引支持，减少排序开销。
4. 灰度验证：先在测试环境对小数据集验证结果一致性，再逐步扩大到生产只读从库观察负载。
怎么验证是否生效
使用 EXPLAIN 命令对比两种写法的执行计划，重点关注 Rows_examined 和 Extra 列。
1. 执行 EXPLAIN FORMAT=JSON SELECT ... 查看查询成本估算。
2. 对比 Rows_examined 数值，窗口函数通常应显著低于子查询扫描行数。
3. 检查 Extra 字段，若出现 Using temporary 或 Using filesort 且数据量大，需评估 sort_buffer_size 配置。
4. 在生产从库开启 slow query log，观察执行时间变化，确认无回归。
常见坑
1. 内存溢出：窗口函数需要在内存中排序，如果未限制 LIMIT 且数据量千万级，可能占用大量内存。
2. 版本兼容：MySQL 5.7 及以下版本不支持窗口函数，代码迁移需判断版本或保留兼容逻辑。
3. 语义差异：窗口函数的 ROW_NUMBER 与用户变量 @rownum 在某些并发或执行计划变化下结果可能不一致，建议统一使用窗口函数。
4. 索引失效：如果 OVER 子句中的排序字段没有索引，优化器可能无法利用索引消除排序步骤。
常见问题
MySQL 5.7 能用窗口函数吗
不能，窗口函数是 MySQL 8.0 引入的新特性，5.7 版本需继续使用子查询或用户变量模拟。
窗口函数一定会比子查询快吗
不一定，如果数据量很小或子查询字段有完美索引覆盖，两者差异不明显，极端情况下窗口函数排序开销可能更大。
如何优化窗口函数的排序性能
确保 OVER 子句中的 ORDER BY 字段建有索引，并适当调整 sort_buffer_size 参数以减少文件排序。
参考来源
- MySQL 官方文档 - Window Functions, https://dev.mysql.com/doc/refman/8.0/en/window-functions.html
- MySQL 8.0 Release Notes, https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-1.html