窗口函数本身不强制全表扫描，其是否触发全表扫描取决于WHERE条件、索引设计和分区策略；数据库先执行过滤等操作生成中间结果集，再在其上计算窗口函数。
窗口函数本身不会强制全表扫描，但是否触发全表扫描取决于查询的其他部分，尤其是 WHERE 条件、索引设计和分区策略。
窗口函数不改变执行计划的基础逻辑
窗口函数（如 ROW_NUMBER()、RANK()、SUM() OVER (...)）是在结果集上“追加计算”，它不参与数据过滤或连接。数据库先执行 FROM、JOIN、WHERE、GROUP BY 等阶段得到中间结果集，再在该结果集上应用窗口计算。
也就是说：如果 WHERE 条件能走索引、返回少量行，那窗口函数只在这些行上运算，不会去碰整张表；反之，若 WHERE 没有有效过滤（比如无条件或用非索引字段），优化器很可能选择全表扫描——但这归因于过滤逻辑，不是窗口函数导致的。
ORDER BY 和框架子句可能影响性能表现
窗口函数中常见的 ORDER BY（用于排序窗口）和 ROWS BETWEEN 等框架定义，会要求数据库对指定分区内的数据做局部排序或累积扫描。这不一定等于全表扫描，但可能带来额外开销：
- 若分区键上有索引，且
ORDER BY字段也包含在该索引中，排序可复用索引顺序，避免额外排序操作 - 若窗口定义为
ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，数据库需读取整个分区的所有行才能计算聚合，此时若分区很大（比如未用 PARTITION BY 或分区粒度太粗），I/O 和内存压力会上升 - 没有
PARTITION BY的窗口函数（即作用于整个结果集），等价于对全部输出行排序/累计，容易成为瓶颈
如何避免意外的全表扫描？
关键不在禁用窗口函数，而在协同优化：
- 确保 WHERE 条件足够精确，并建立合适索引，让扫描范围从“全表”缩小到“必要子集”
- 合理使用 PARTITION BY，把大窗口拆成多个小分区，让每个分区可独立、高效处理
- 检查执行计划（EXPLAIN），确认实际扫描行数与预估是否一致，关注 “Seq Scan”、“Index Scan”、“Sort” 等节点的代价
- 避免在窗口函数中嵌套复杂子查询或标量子查询，这类写法容易打断优化器的路径选择，诱发低效执行
不同数据库的细微差异
PostgreSQL、SQL Server、Oracle 对窗口函数的支持较成熟，优化器通常能较好下推过滤条件；MySQL 8.0+ 支持窗口函数，但早期版本优化能力有限，某些场景下可能更倾向物化中间结果；ClickHouse、Doris 等 OLAP 引擎则通过列存+分区剪枝天然规避传统“全表扫描”问题，但要注意窗口函数是否触发跨分片重分布。
不复杂但容易忽略：窗口函数是“锦上添花”，不是“雪中送炭”。它的性能底限，始终由前面的数据筛选和组织方式决定。
