SQL实时统计需权衡延迟、一致性和运维成本：明确实时边界（监控5–30秒、风控亚秒级、看板T+0微批），避免全表扫描，采用分层聚合、分区覆盖、近似算法；保障一致性需事件时间打标、水位线、幂等写入；并具备可观测与降级能力。
SQL实时统计不是简单写个 SELECT COUNT(*) 加个定时任务就能搞定的事。核心在于：数据源是否支持增量捕获、计算逻辑能否低延迟响应、结果能否可靠落地并被业务系统消费。设计不当容易陷入“伪实时”——看着刷新快，实际数据滞后几分钟甚至丢数。
明确实时性边界：先定义“实时”到底要多快
不同场景对“实时”的要求差异巨大：
- 监控大屏类：允许 5–30 秒延迟，可用流式聚合（如 Flink + Kafka）或物化视图（如 ClickHouse ReplacingMergeTree + FINAL）
- 风控决策类：要求亚秒级响应，需内存计算引擎（如 Redis HyperLogLog / Sketches）或预聚合+索引加速（如 Doris Rollup 表）
- 用户行为看板：T+0 但非强实时，可走微批（1 分钟窗口）+ 增量更新（如 Delta Lake MERGE）
不提前划清 SLA，后续所有技术选型都会跑偏。
避免直接查原始明细表：用分层聚合代替全表扫描
常见误区是每次统计都 SELECT COUNT(*) FROM events WHERE dt = '2024-06-15' AND type = 'click' —— 数据量一过千万，IO 和锁就成瓶颈。
- 建轻量级汇总表：按小时/分钟粒度预存 UV/PV/金额总和，字段精简（只留维度+指标）
- 用分区表 + 覆盖写入：Hive/Trino 支持
INSERT OVERWRITE PARTITION(dt='...')，避免全量重算 - 对高基维（如 user_id）用近似算法：PostgreSQL 的
approx_count_distinct()，或 ClickHouse 的uniqCombined()
保障数据一致性：别让“实时”牺牲正确性
为提速而跳过去重、忽略乱序、容忍重复写入，短期省事，长期难维护。
- 事件时间（event_time）必须打标：在数据接入时就提取真实发生时间，而非处理时间（processing_time）
- 设置水位线（watermark）：Flink 或 Spark Structured Streaming 中配置，容忍有限乱序，避免无限等待
- 幂等写入：目标表主键/唯一约束 + UPSERT 语义（如 Doris REPLACE WHEN、Databricks MERGE），防止同一条记录多次计入
可观测与降级能力：实时链路必须能“看见”和“刹得住”
没有监控的实时任务等于盲开高速车。
- 埋点关键指标：端到端延迟（从事件产生到看板更新）、输入 QPS、处理失败率、checkpoint 间隔
- 配置自动告警：延迟 > 30s、连续 3 次 checkpoint 失败、输出为空，立刻通知
- 预留降级开关：比如切回 T+1 离线快照表，或返回缓存中最近一次有效结果（带时间戳标识）
基本上就这些。实时统计不是堆技术，而是权衡延迟、一致性和运维成本后的精准设计。不复杂，但容易忽略细节。
