窗口函数在千万级表上慢因需全分区排序与扫描，索引缺失或数据倾斜会引发磁盘排序甚至oom；临时表预聚合仅适用于结果远小于原表、逻辑稳定、可接受延迟的场景。
为什么窗口函数在千万级表上会慢得像卡住
因为窗口函数默认需要对整个分区做排序 + 累计扫描，如果 PARTITION BY 字段选择不当、缺少索引，或数据倾斜严重，就会触发大量磁盘临时排序（tempdb 或 pg_temp），甚至 OOM。尤其当 ORDER BY 涉及非索引字段时，PostgreSQL 会强制 materialize 全部分区；MySQL 8.0 在无覆盖索引时也会退化为全表扫描+filesort。
用临时表预聚合替代实时窗口计算的实操条件
不是所有窗口场景都适合临时表，只有满足以下全部条件时，才值得拆：结果集远小于原始表（比如按天聚合用户行为，原始表亿级，结果仅万级）；聚合逻辑稳定（不频繁变更 ROWS BETWEEN 范围或 LAG/LEAD 偏移量）；业务能接受 T+1 或分钟级延迟。
- 先建带索引的临时表：
CREATE TEMP TABLE user_daily_stats AS SELECT user_id, DATE(event_time) AS dt, COUNT(*) AS cnt, SUM(duration) AS total_dur FROM events WHERE event_time >= CURRENT_DATE - INTERVAL '7 days' GROUP BY user_id, DATE(event_time); - 在临时表上加复合索引：
CREATE INDEX ON user_daily_stats (user_id, dt)—— 这是后续模拟ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW的关键 - 用自连接或
LATERAL替代原窗口函数，例如累计求和：SELECT a.user_id, a.dt, (SELECT SUM(cnt) FROM user_daily_stats b WHERE b.user_id = a.user_id AND b.dt
临时表方案下必须避开的三个坑
临时表不是银弹，踩错一步性能反而更差。
- 别在临时表里留冗余大字段：如果原表有
jsonb或text描述列，但聚合不需要，就别SELECT *，否则临时表体积暴涨，索引失效 - 别忽略统计信息更新：PostgreSQL 临时表默认无统计信息，执行前必须跑
ANALYZE user_daily_stats，否则查询计划可能选错连接方式 - 别复用同一张临时表跨事务：MySQL 临时表在 session 结束即销毁，PostgreSQL 临时表默认只在当前事务有效；若需多次使用，得显式声明
ON COMMIT PRESERVE ROWS（PG）或改用普通表+命名空间隔离
什么时候该放弃临时表，转投物化视图或增量更新
当你的“窗口”逻辑开始依赖动态参数（比如前端传来的 @window_days）、或者需要 sub-second 响应时，临时表预聚合就撑不住了。这时候得切到更重的方案：PostgreSQL 用 REFRESH MATERIALIZED VIEW CONCURRENTLY 配合定时任务；MySQL 则建议用 INSERT ... ON DUPLICATE KEY UPDATE 维护汇总表，并用 event_time 作为增量位点。核心判断标准只有一条：你能否把「窗口边界」转化成确定的、可索引的谓词条件。
