17370845950

实时统计核心是平衡更新节奏、响应延迟与资源开销；80%问题源于设计阶段未厘清“实时”边界（毫秒/秒级/准实时）、“统计”口径及系统承载力。

SQL实时统计不是靠单条SELECT语句堆出来的，核心在于数据更新节奏、查询响应延迟、资源开销三者的平衡。真正落地时，80%的问题出在设计阶段——没想清楚“实时”到底要多实、“统计”到底要算什么、“系统”到底能扛住什么。

明确“实时”的边界：毫秒级？秒级？还是准实时？

不同业务对“实时”容忍度差异极大。下单后10秒内看到销量变化，和风控场景下200ms内判断交易异常，技术方案完全不一样。

• 毫秒级（：基本绕不开内存计算（如Redis HyperLogLog、Flink状态后端），纯SQL很难扛住，慎用“SQL实时”当宣传话术
• 秒级（1–5s）：可基于物化视图（PostgreSQL 14+）、增量刷新的汇总表（MySQL+定时UPDATE）、或ClickHouse实时表引擎（ReplacingMergeTree + FINAL）
• 准实时（30s–5min）：最常用也最稳妥。用轻量ETL（如dbt + cron）每分钟跑一次聚合写入宽表，再用普通SQL查，稳定、易调试、好监控

避免全表扫描：给统计加“锚点”和“分区”

一查就慢，90%是因为没约束时间范围或没利用索引。实时统计不是“查全部”，而是“查最新一段”。

• 所有统计SQL必须带时间过滤条件，且字段要有索引——比如WHERE event_time >= NOW() - INTERVAL '60 seconds'，配合event_time上的B-tree索引
• 大表务必按时间分区（PostgreSQL range partition / MySQL PARTITION BY RANGE / ClickHouse PARTITION BY toYYYYMMDD）。删旧分区比DELETE快十倍，查新分区也只扫1/100的数据
• 高频统计维度（如user_id、order_status）建复合索引，顺序按“过滤+分组+排序”排列。例如：查询“每个城市昨日支付成功订单数”，索引应为(pay_status, city, pay_time)

用好物化与缓存：别让同一张表被反复算

用户刷屏看仪表盘，后端却每秒执行5次一样的SUM(CASE WHEN …)，这是典型的设计浪费。

• 把高频、固定口径的统计结果提前算好，存成独立汇总表。比如每分钟生成minute_order_summary，含ts_min, city, paid_cnt, amount_sum
• 用数据库原生物化能力：PostgreSQL可用REFRESH MATERIALIZED VIEW CONCURRENTLY；MySQL可用触发器+汇总表（注意高并发写冲突）；Doris/StarRocks直接建物化视图自动维护
• 加一层应用缓存（如Redis），键名带版本和时间戳，例如stat:city_orders:20250520:14，TTL设为65秒，既防穿透又保新鲜

监控不是锦上添花，而是实时统计的生命线

没有监控的实时统计，等于没上线。延迟涨了、数据断了、结果不准了，没人知道。

• 必埋三个指标：① 统计任务延迟（从事件发生到结果可查的时间差）；② 查询P95耗时；③ 汇总表最新记录时间戳与当前时间的差值
• 用简单SQL做健康检查：比如SELECT MAX(event_time) FROM events，如果超过15秒没更新，立刻告警
• 每天自动校验关键统计值是否突变（如环比±50%），用脚本比对汇总表和明细表抽样结果，早于用户发现异常

基本上就这些。不复杂，但容易忽略细节。真正的实战能力，不在写多炫的窗口函数，而在想清楚“谁要什么、什么时候要、能等多久、错一点行不行”。