实时统计需协同数据流模型、状态管理与时间语义；必须用窗口（滚动/滑动/会话）建模时间范围，依赖事件时间与水位线保障精度，状态须持久化检查点防丢数。
SQL实时统计不是简单写个SELECT COUNT(*)就完事，它本质是“在数据持续流入时，低延迟、高精度地给出聚合结果”。设计的核心不在SQL语法本身，而在**数据流模型 + 状态管理 + 时间语义**三者的协同。理解这三点，才能避开“查出来总是旧的”“窗口乱跳”“吞吐一高就丢数”这些典型坑。
流式处理 vs 批处理：实时统计的第一道分水岭
传统SQL跑在静态表上，执行完就结束；实时统计面对的是无限增长的数据流（比如订单日志、用户点击）。你不能等“所有数据来齐”，必须边来边算。
- 批处理视角：把一小时的日志当一个文件读，COUNT一次得出总数——结果准，但延迟60分钟+
- 流处理视角：每来一条订单，立刻更新“当前5分钟内总金额”，用滑动窗口或会话窗口切分时间范围
- 关键区别：流SQL必须显式声明时间字段（如
event_time）和水位线（Watermark），否则系统无法判断“哪些迟到数据还能补进窗口”
窗口（Window）不是可选功能，而是必选建模工具
没有窗口，实时统计就失去业务意义。“当前销量”“最近10分钟错误率”“用户会话时长”全依赖窗口定义。常见类型不是概念罗列，而是按业务逻辑选：
-
Tumbling Window（滚动窗口）：固定长度、不重叠，适合日报/小时报。例：
TUMBLING (SIZE 1 MINUTE)—— 每分钟清零重算，简单可靠 -
Hopping Window（滑动窗口）：固定步长+固定长度，有重叠，适合监控告警。例：
HOPPING (SIZE 10 MINUTES, INTERVAL 1 MINUTE)—— 每分钟输出一次“过去10分钟”的累计值 - Session Window（会话窗口）：按用户行为间隙自动合并，适合分析单次访问。例：用户30分钟无操作即断开会话，期间所有点击归为一个会话统计
状态（State）和容错：为什么你的实时任务一重启就丢数？
流SQL要记住“已处理到哪了”“当前窗口累加了多少”，这些中间结果就是状态。它存在内存里，但机器挂了怎么办？答案是：必须持久化 + 检查点（Checkpoint）。
- 状态后端选
rocksdb（推荐）而非内存，支持大状态且落盘可靠 - 检查点间隔设为10~30秒，太短拖慢性能，太长重启恢复久
- 务必开启
enableCheckpointing和setExternalizedCheckpointCleanup，否则任务失败后状态丢失
时间语义：事件时间（Event Time）才是实时统计的黄金标准
用处理时间（Processing Time）统计，等于看服务器时钟——网络延迟、程序卡顿都会让结果失真。真实业务看的是“用户下单那一刻”，也就是事件时间。
- 数据源中必须含准确的时间戳字段（如
order_time），且格式为毫秒级Long或TIMESTAMP - 建表时显式声明：
WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND—— 允许最多5秒迟到数据参与计算 - 窗口触发时机由水位线驱动，不是定时器。水位线推进，才真正输出窗口结果
基本上就这些。不复杂但容易忽略——多数人卡在没想清楚“我要统计什么时间范围内的什么，容忍多少延迟”，就急着写GROUP BY。先把窗口类型、时间字段、状态存哪这三个问题钉死，SQL只是自然浮现的表达而已。
