子查询无法实现真正的流式统计，必须用窗口函数替代；标准sql无“流式”概念，所谓时间窗口统计依赖over()配合range/rows帧，如range between interval '5 minutes' preceding and current row，而非嵌套子查询。
子查询不能直接实现流式统计，得用窗口函数代替
SQL 标准里没有“流式”概念，传统子查询是静态快照式执行，无法持续响应新数据。所谓“按时间窗口的流式统计”，实际依赖的是 OVER() 窗口函数（如 ROW_NUMBER()、AVG()、COUNT() 配合 PARTITION BY 和 ORDER BY），而不是嵌套子查询。
常见误操作：写一个子查询去查 WHERE event_time >= NOW() - INTERVAL '5 minutes'，然后外层再聚合——这只能跑一次，且每次执行都重算全量，不是流式，也不高效。
- 真正支持近实时窗口统计的系统（如 Flink SQL、Trino、ClickHouse、Doris）都要求用
OVER (ORDER BY event_time RANGE BETWEEN INTERVAL '5' MINUTE PRECEDING AND CURRENT ROW)这类语法 - MySQL 8.0+、PostgreSQL、Snowflake 支持标准窗口函数，但不自带“自动触发”机制；需配合外部调度或物化视图刷新
- 如果硬要用子查询模拟滑动窗口（比如每分钟拉一次过去5分钟数据），必须由应用层控制执行频率，且要注意
event_time字段是否带时区、是否已索引
PostgreSQL 中用 RANGE 窗口实现 5 分钟滑动均值
关键在 RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW —— 它按时间值滑动，不是按行数，更适合事件时间语义。
SELECT
event_time,
AVG(value) OVER (
ORDER BY event_time
RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW
) AS avg_5min
FROM sensor_data
WHERE event_time >= NOW() - INTERVAL '1 hour';
注意点：
-
RANGE要求ORDER BY字段是单调可比较类型（如TIMESTAMP），不能是TEXT或未解析的时间字符串 - 若存在多条相同
event_time的记录，RANGE会把它们全包含进当前窗口，可能造成突刺；可用ROWS BETWEEN ...控制行数，但失去时间语义 - 该查询不会“持续运行”，只是快照计算；要流式效果，得结合
pg_cron定时刷视图，或用逻辑复制 + LISTEN/NOTIFY 推送变更
Flink SQL 的 HOP 窗口比子查询更贴近“流式”本意
如果你真需要低延迟、状态保持、水位线驱动的窗口统计，Flink SQL 是目前最接近“流式”原生语义的方案，它根本不用子查询，而是用声明式窗口：
SELECT HOP_START(event_time, INTERVAL '30' SECONDS, INTERVAL '5' MINUTES) AS window_start, COUNT(*) AS cnt FROM clicks GROUP BY HOP(event_time, INTERVAL '30' SECONDS, INTERVAL '5' MINUTES);
说明：
-
HOP是滑动窗口，每 30 秒触发一次，覆盖最近 5 分钟数据；TUMBLING是翻滚窗口（不重叠），SESSION是会话窗口 - 子查询在这里完全无用武之地——Flink 不支持在
GROUP BY中嵌套非确定性子查询 - 必须定义
WATERMARK，否则乱序事件会导致结果不准：WATERMARK FOR event_time AS event_time - INTERVAL '10' SECONDS
为什么有人坚持用子查询？常见陷阱与替代建议
有些场景看似适合子查询，实则埋了坑：
- 想“先过滤出最近一小时数据，再按设备分组统计” → 错误：子查询过滤后丢失了跨窗口的时序关系；应改用
PARTITION BY device_id ORDER BY event_time窗口 - 用子查询查最大时间戳再关联原表 → 性能灾难，尤其在大表上；
MAX(event_time) OVER (PARTITION BY device_id)更高效 - 在 WHERE 中写
id IN (SELECT id FROM logs WHERE ts > NOW() - '5min')→ 这是“最近5分钟有哪些ID”，不是“每个ID在过去5分钟内的统计”，语义错位
真正需要子查询的场合极少，比如补全维度信息（SELECT *, (SELECT name FROM devices d WHERE d.id = l.device_id)），而非时间窗口计算本身。
时间窗口统计的核心从来不是“怎么嵌套”，而是“怎么定义边界、怎么处理乱序、怎么落地更新”。子查询在这里只是障眼法，越早切换到窗口函数或流计算引擎，越少掉坑里。
