窗口函数执行计划的关键是观察其上下游数据流动是否可控，重点检查SQL Server的Window Spool、PostgreSQL的WindowAgg上游、MySQL的window_function子树及TiDB的cop_task中Window下推情况，并确保索引覆盖、统计信息准确、分区键均衡。
SQL Server 里怎么看窗口函数是否走对了执行计划
窗口函数本身不会单独生成一个“窗口算子”节点，而是被合并进整个执行计划树里——关键看 Window Spool、Segment Top、Sequence Project 这几类物理运算符有没有出现，以及它们的输入是否来自索引查找（Index Seek）而非扫描（Table Scan 或 Clustered Index Scan）。
直接按 Ctrl+L 或 Ctrl+M 在 SSMS 中打开图形执行计划，重点观察：
- 最右侧叶节点是否是高效的数据源（比如带谓词的
Index Seek），而不是全表扫描 - 中间是否有
Window Spool：这是 SQL Server 实现窗口函数（如ROW_NUMBER()、RANK()）的核心算子，它会把数据按PARTITION BY分组、按ORDER BY排序后缓存，再逐行输出结果 -
Window Spool的“Estimated Rows”和“Actual Rows”是否接近：如果偏差大（比如估 100 行，实际 10 万行），说明统计信息过期或分区键选择不当，可能触发大量内存授予（Grant KB显著升高）甚至溢出到 tempdb
PostgreSQL 中窗口函数执行计划的关键字段
用 EXPLAIN (ANALYZE, BUFFERS) 查看，窗口函数不会单独列成一行，但会体现在 WindowAgg 节点中。这个节点本身不读磁盘，真正影响性能的是它的上游——也就是排序和分组所依赖的数据访问方式。
重点关注三处：
-
Sort Method: external merge：说明排序撑爆 work_mem，落盘了，必须调大work_mem或加索引覆盖PARTITION BY + ORDER BY字段 -
Buffers: shared hit=xxx值很大，但read=0：说明数据全在缓冲区，但排序/窗口计算本身开销高，需检查是否冗余计算（比如同一窗口定义在多个列里重复使用） - 没有
Index Scan using xxx on table_name，却有Sort节点：说明缺少能支持PARTITION BY a, ORDER BY b的复合索引，排序成了瓶颈
MySQL 8.0+ 窗口函数执行计划识别要点
MySQL 不显示 WindowAgg 类节点，窗口函数逻辑被折叠进 WINDOW 操作符下，但执行计划里会明确标出 type: window_function 和 Extra 字段里的提示。
运行 EXPLAIN FORMAT=TREE 后，注意：
- 是否存在
-> Window function子树，且其上层是-> Sort：这表示 MySQL 必须先排序再计算窗口，没走索引优化 -
Extra列含Using temporary; Using filesort：双重警告，意味着既用了临时表又做了文件排序，基本等于没走索引 - 如果
key列为空，但表上有(dept_id, hire_date)索引，而查询是ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY hire_date)，那说明索引没被复用——MySQL 8.0.23+ 才支持该场景下的索引下推，旧版本只能回表或全排序
TiDB 中窗口函数执行计划的特殊验证点
TiDB 的执行计划里会出现 Window 算子，但它不等价于物理执行动作；真正决定性能的是上游是否命中 TiKV 的 Region 扫描优化，以及是否触发 Coprocessor 下推。
查 EXPLAIN ANALYZE 输出时，盯住：
-
cop_task是否包含Window：如果有，说明窗口计算被下推到 TiKV 层，是理想状态；如果只有Selection、Projection，那窗口逻辑全在 TiDB 层做，容易 OOM -
estRows和actRows差异巨大（比如估 1k，实跑 100w）：常见于未 ANALYZE 的分区表，或WINDOW子句里引用了未统计字段（如uids），TiDB 会报错但计划仍生成，此时buildWindowSpecs阶段已校验失败 -
time字段中Window算子耗时占比超过 60%：大概率是PARTITION BY字段区分度低（比如全是 0/1），导致单个 TiKV Region 处理过多分组，需要打散或加 hint 强制 shuffle
窗口函数的执行计划不是看有没有那个节点，而是看它上下游的数据流动是否可控、可预测。索引是否覆盖、统计信息是否新鲜、分区键是否倾斜——这些细节比算子名字重要得多。
