SQL实时统计需协同数据流、状态维护与窗口计算，非简单SELECT；“实时”指亚秒至分钟级低延迟；窗口是逻辑切片机制，状态是累计记忆体，须配水位线、窗口字段及upsert目标表。
SQL实时统计不是“写个SELECT就完事”，核心在于数据流、状态维护和窗口计算三者协同。传统批处理SQL按固定数据集算一次，而实时统计要持续响应新到来的每一条数据，并在合理时间范围内给出准确结果。理解这几个关键概念，设计才不会走偏。
什么是“实时”？别被字面骗了
实时 ≠ 毫秒级响应。工程中常见的“实时”其实是亚秒到分钟级延迟（low-latency）的持续计算。比如用户行为看板更新延迟3秒可接受，但订单对账必须准且不能丢数据。关键看业务容忍度——是追求快，还是追求准，或是两者都要？这直接决定技术选型：
- 纯事件驱动+内存聚合（如Flink的KeyedState）：适合高吞吐、低延迟场景，但需自己管容错
- 带事务日志的流表二象性（如Flink SQL的CREATE TABLE WITH 'connector'='kafka'）：自动对齐水位线、支持Exactly-once
- Lambda架构（批+流双跑）：适合强一致性要求又难一步到位的过渡方案
窗口（Window）不是“划时间框”，而是定义“怎么攒数据”
窗口本质是对无界数据流做有界切片的逻辑机制，不是简单按钟表时间切。常见类型背后逻辑不同：
- Tumbling Window（滚动窗口）：严格不重叠，比如每5秒统计一次PV。适合监控类指标，“干净利落”但可能错过跨窗口的行为关联
- Hopping Window（滑动窗口）：步长小于窗口长，比如窗口10秒、每2秒滑动一次。适合“最近10秒内最高QPS”这类需求，计算开销大但灵敏度高
- Session Window（会话窗口）：按用户活跃间隙自动分组，比如30分钟无操作则断开会话。依赖事件时间+水位线，最贴近真实业务语义
注意：窗口触发时机受事件时间（event time）、处理时间（processing time）和水位线（watermark）共同影响。用错时间语义，统计结果就会“看起来对、实际错”。
状态（State）是实时统计的“记忆体”，不是可有可无
没有状态，就只能算当前这一条；有了状态，才能累计、去重、排序、关联。比如“每个用户今天点击次数”，必须记住用户ID和计数——这个键值对就是状态。
- 状态默认存在TaskManager内存里，重启会丢（除非启用Checkpoint）
- 大状态要用RocksDB后端，避免OOM；但访问变慢，需权衡
- 状态TTL很重要：不清理的老用户数据会越积越多，拖慢性能甚至OOM
- KeyedState（按key隔离）是主流，避免不同用户的统计互相干扰
SQL怎么写才算“真正实时”？看这三点
很多同学写了个INSERT INTO ... SELECT ... FROM kafka_table GROUP BY TUMBLING... 就以为是实时了。其实还要确认：
- 源表是否声明了WATERMARK？没它，乱序事件会导致结果不准
- GROUP BY里有没有window_start / window_end字段？否则窗口信息丢失，下游无法对齐时间维度
- 目标表是否支持upsert或changelog语义？只支持追加写入（append-only）的目标（如普通Kafka Topic），无法更新“过去某窗口的统计值”
基本上就这些。把流、窗、态、时四者串起来想，SQL实时统计就从“玄学”变成“可推演、可调试、可优化”的工程实践。
