SQL实时统计核心是预聚合而非查询优化，需按数据更新频率、查询维度和延迟容忍度分层设计，结合物化视图、持续查询与缓存兜底。
SQL实时统计不是靠“查得快”，而是靠“算得巧”——核心是把计算提前做、分层存、按需取。真正落地时，90%的问题出在设计阶段：没想清楚数据更新频率、查询维度、延迟容忍度，就直接写COUNT(*)和GROUP BY，结果一上生产就卡顿或不准。
用物化视图/汇总表预聚合，别总查原始明细
高频统计如“每分钟订单数”“各城市实时销量TOP10”，若每次查询都扫全量订单表，哪怕加了索引也扛不住每秒百次请求。正确做法是提前聚合，定时（如每10秒）或触发式（如新订单入库后）更新汇总表。
- 建一张minute_summary表：字段包括dt_minute（'2024-06-15 14:23'）、city、order_cnt、amount_sum
- 用定时任务（如Airflow或数据库内置事件）每10秒执行：
INSERT INTO minute_summary SELECT date_trunc('minute', created_at), city, COUNT(*), SUM(amount) FROM orders WHERE created_at > ? GROUP BY 1,2（注意WHERE条件限制扫描范围） - 查询时直接查minute_summary，毫秒级响应，且结果天然“准实时”
窗口函数 + 持续查询，适合流式场景（如Flink/Trino/Kafka+ClickHouse）
当数据持续写入（如IoT设备心跳、用户点击日志），需要“边写边算”，就不能依赖定时批处理。此时用支持持续查询的引擎更合适。
- ClickHouse示例：建ReplacingMergeTree表 + MATERIALIZED VIEW自动聚合
CREATE MATERIALIZED VIEW order_1min_mv TO minute_summary AS SELECT toStartOfMinute(created_at) AS dt, city, count() AS cnt FROM orders GROUP BY dt, city - Flink SQL中直接写：
SELECT TUMBLING_START(ts, INTERVAL '1' MINUTE), city, COUNT(*) FROM clicks GROUP BY TUMBLING(ts, INTERVAL '1' MINUTE), city - 关键点：窗口必须对齐（如整点分钟），避免重复或遗漏；状态要可恢复，防止重启丢数
加缓存层兜底，防突发查询打垮DB
即使做了预聚合，也可能遇到“老板突然要看过去5分钟每10秒的转化率”，这种临时高维下钻查询仍可能慢。这时缓存不是可选项，是必选项。
- 用Redis Hash或JSON存储最近15分钟的分钟级指标：
HSET stats:20240615:14 "14:23" '{"cnt":182,"rate":0.32}' - 应用层先查Redis，命中则返回；未命中再查数据库，并异步回填缓存
- 设置合理过期时间（如18分钟），保证数据不陈旧，又避免缓存雪崩
警惕“实时”陷阱：区分业务延迟与技术延迟
很多需求说“要实时”，但实际能接受30秒延迟？还是必须1秒内？这个边界决定技术选型。盲目追求毫秒级，可能引入Kafka+Flink+Redis整套链路，运维成本翻倍，而业务根本感知不到差别。
- 监控类看板（如服务器CPU趋势）：30秒延迟完全可接受 → 用定时汇总+缓存足够
- 风控规则（如“1分钟内登录失败5次封IP”）：必须亚秒级 → 上Flink CEP或Redis Sorted Set计数
- 电商大促看板：前端轮询每5秒一次 → 后端只要保证5秒内数据更新即可，不必强求“真流式”
基本上就这些。不复杂但容易忽略：先定义好“实时”到底指什么，再选路；宁可多建一张汇总表，也不要让核心查询扫千万行；缓存不是锦上添花，是实时系统的安全气囊。
