SQL实时统计需兼顾高并发、低延迟与可维护性，核心在于结构设计、节奏控制与风险规避，通过物化视图+增量刷新、窗口函数精准截取、CTE分步逻辑、缓存代理层等手段实现可控实时。
SQL实时统计不是简单写个COUNT(*)或GROUP BY就完事——它得扛住高并发、数据持续流入、结果秒级可见，还要能灵活响应业务维度变化。核心不在“会不会写”，而在“怎么组织结构+怎么控制节奏+怎么避免翻车”。下面用一个真实电商后台的实时销量看板案例拆解关键设计逻辑。
用物化视图 + 增量刷新替代全量扫描
某平台需每30秒更新“近1小时各品类销量Top10”。若每次查原始订单表（日增500万+记录），即使加索引也会拖慢查询、挤占资源。
- 建一张轻量汇总表
sales_summary_1h，只存category_id、hour_start、total_qty、updated_at - 用定时任务（如Airflow或pg_cron）每30秒执行一次增量聚合：
INSERT ... SELECT ... FROM orders WHERE created_at > last_updated AND created_at
（跳过最新1分钟数据，防未提交事务干扰） - 配合
ON CONFLICT (category_id, hour_start) DO UPDATE做幂等合并，避免重复累加
窗口函数精准截取“滚动最近N条”而非模糊时间范围
运营要查“每个用户最近3次下单的平均间隔（小时）”，不能简单WHERE order_time > NOW() - INTERVAL '7 days'——活跃用户数据多，沉默用户可能压根没7天内订单，结果偏差大。
- 用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_time DESC)给每人订单倒序编号 - 外层过滤
rn ，再用LAG()算相邻两次时间差，最后AVG() - 这样无论用户是高频还是低频，都严格取“最近3次”，语义清晰、结果稳定
用CTE分步隔离逻辑，避免嵌套过深导致可读性崩塌
统计“昨日新客中，24小时内完成首单且复购率>15%的城市”涉及新客识别、首单时效判断、复购行为追踪三层逻辑，硬写成一长串JOIN极易出错。
- 第一段CTE：
new_users AS (SELECT DISTINCT user_id FROM users WHERE register_time::date = CURRENT_DATE - 1) - 第二段CTE：
first_orders AS (SELECT user_id, MIN(order_time) AS first_time FROM orders WHERE user_id IN (SELECT user_id FROM new_users) GROUP BY user_id) - 第三段CTE：
qualified_users AS (SELECT user_id FROM first_orders WHERE first_time - (SELECT register_time FROM users u WHERE u.user_id = first_orders.user_id) - 主查询再JOIN订单表统计这些用户的复购次数，按城市聚合
加一层“缓存代理层”应对突发流量，不把压力全丢给数据库
大促期间看板QPS从200飙到2000，DB直连必然抖动。我们没上Redis存结果，而是用PostgreSQL的MATERIALIZED VIEW + 定时REFRESH + 应用层缓存兜底：
- 物化视图本身带数据快照，REFRESH CONCURRENTLY不锁表
- 应用读取时先查物化视图；若超5秒未更新，降级查原始表并异步触发强制刷新
- 前端加本地缓存（localStorage）存15秒结果，避免用户狂点刷新按钮造成无效请求
基本上就这些。实时不是追求“绝对零延迟”，而是让延迟可控、逻辑可维护、结果可验证。别迷信流计算框架——很多场景，用好SQL的增量、窗口、CTE和物化能力，比搭一套Flink作业更稳、更快、更省心。
