窗口函数在普通视图中查询慢，是因为视图不存储数据且每次查询都需重执行全量子查询与排序；即使加WHERE或LIMIT，优化器仍常先计算全部窗口值再过滤，导致百万级数据时性能骤降。
为什么窗口函数在普通视图里一查就慢
因为视图只是保存 SQL 语句的“快捷方式”，不存数据，也不预计算。只要视图里用了 ROW_NUMBER()、RANK() 或 SUM() OVER () 这类窗口函数，每次查询都会重跑整个子查询 + 全量排序/分组 —— 数据量一过百万，EXPLAIN 里准能看到 WindowAgg 节点挂在最顶层，且 Buffers 飙升。
常见症状：SELECT * FROM my_analytics_view LIMIT 10 要 8 秒；加了 WHERE 条件也几乎不提速；ORDER BY 字段和窗口的 PARTITION BY 不一致时更卡。
- 窗口函数必须看到完整分区数据才能出结果，无法用传统 B-tree 索引跳过中间行
- PostgreSQL / MySQL 8.0+ / SQL Server 的视图都不支持对窗口结果建索引
- 即使在外层加
WHERE，优化器往往仍要先算完所有窗口值再过滤（除非有明确的分区剪枝条件）
物化视图不是万能解药：哪些数据库真支持
物化视图（Materialized View）能缓存结果，但支持程度差异极大 —— 别被文档标题骗了。
-
PostgreSQL：原生支持
CREATE MATERIALIZED VIEW，但REFRESH是全量重算，且不能自动刷新；窗口函数结果可被物化，但若基表更新频繁，REFRESH CONCURRENTLY要求唯一索引，而窗口函数输出通常没主键 -
MySQL：没有物化视图；
CREATE TABLE AS SELECT是替代方案，但需手动维护，且INSERT ... SELECT带窗口函数时可能锁表 -
SQL Server：用索引视图（Indexed View），但窗口函数是明确禁止的——创建会直接报错
Msg 10127, Level 16 -
Oracle：支持物化视图，但带窗口函数的查询默认不被允许快速刷新（
FAST REFRESH），需改写为聚合+分析函数组合，且依赖物化视图日志结构
关键判断：如果业务要求秒级实时性，物化视图基本不可用；如果能接受分钟级延迟，PostgreSQL 是目前最省心的选择。
绕过窗口函数性能瓶颈的实操路径
与其硬扛窗口函数的计算开销，不如把逻辑拆到写入或预处理阶段。以下方法在真实 OLAP 场景中验证有效：
- 在 ETL 或应用写入时，用触发器或应用层补全排名字段：比如插入订单时，用
SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = NEW.user_id AND o2.created_at <= NEW.created_at算“用户第几单”，存成普通列 —— 后续查WHERE user_rank = 1就能走索引 - 用临时表 + 分区表模拟物化：按天/周建分区表
sales_ranks_202405，每天凌晨跑一次INSERT INTO sales_ranks_202405 SELECT user_id, ..., ROW_NUMBER() OVER (PARTITION BY region ORDER BY amount DESC) AS rank ...，查询时FROM sales_ranks_* JOIN ...，配合分区裁剪，性能接近物理表 - 对高频访问的窗口维度（如“每个品类销量 Top 10”），单独建宽表并加复合索引：
CREATE INDEX idx_category_top10 ON category_top10 (category_id, rank)，比在视图里反复算快一个数量级
索引对窗口函数本身无效，但能加速它的前置条件
给视图定义里的基表字段建索引，不会让 ROW_NUMBER() OVER (ORDER BY created_at) 变快，但能显著提升它依赖的过滤与连接效率。
- 确保
PARTITION BY字段有索引：比如OVER (PARTITION BY user_id ORDER BY ts)，则(user_id, ts)复合索引能让每个分区内的排序免排序（Index Scan Backward） - 外层
WHERE条件字段必须索引：如果视图常被WHERE status = 'active'调用，就在基表上建status索引，否则窗口计算前得先扫全表过滤 - 避免在窗口函数中用表达式：写成
ROW_NUMBER() OVER (ORDER BY lower(name))会让索引失效；应提前在基表存name_lower并索引
真正容易被忽略的是：窗口函数的性能瓶颈往往不在“算排名”本身，而在“找数据”的过程。优化顺序永远是 —— 先缩小扫描范围，再考虑是否物化，最后才轮到调优窗口语法。
