上个月加了个周六的班，就为一个接口。

运营后台的订单统计页，P99耗时稳定在2.8秒，高峰期冲到4秒开外。运营点个"今日GMV"要转圈半天，老板看数据大屏卡了一次，直接在群里@技术，问是不是服务器没续费。

讲真，这种活最不讨喜。业务跑得好好的没人记得你，卡了全是你的锅。

但捋下来发现问题比想象中有意思——不是简单"加个索引"就能搞定，而是从数据库选型、缓存策略到对账补偿的一整套方案。最终接口从2.8秒干到30毫秒，今天把整个过程拆给你看，下次遇到类似场景直接抄作业。

## 先说结论：不是SQL写得烂，是思路从根上错了

还原一下现场。那个接口是典型的运营统计需求：按时间范围、渠道、状态、商品分类等维度，统计订单数、GMV、客单价、退款率，前端还带分页明细。

原来的写法最朴素——前端传参，Service拼SQL，MySQL执行count、sum、group by，MyBatis映射成VO返回。逻辑看着没毛病，代码也干净。

问题出在数据量。订单主表500多万行，每天还在以几万条增长。运营最爱干什么？选最近30天，不选状态，按分类group by，再加个分页导出。一条SQL扫几十万行，在临时表里排序分组，磁盘临时表都给你跑出来，不慢才怪。

第一反应也是"加索引"。

冷静下来想，这治标不治本。统计型查询和业务型查询不一样。业务查询是"找某条具体数据"，索引能精准命中；统计查询是"算一堆数据的汇总"，就算建了覆盖索引，InnoDB的count(\*)依然要把匹配到的每一行扫一遍逐行计数，几十万行就是几十万次IO。多维度任意组合的情况，索引建少了不顶用，建多了写入维护成本爆炸。

本质问题是：**你在用MySQL干它不擅长的活——实时大批量聚合计算。**

想明白这点，方案就清晰了：把"查询时实时算"改成"写入时同步算"，也就是**预聚合**。

## 方案选型：为什么最终选了MySQL+Redis

动手之前先列了几种思路，逐个对比。

**SQL优化+索引**：短期有效，长期无解。组合维度一多索引根本覆盖不过来，count(\*)本身就是InnoDB弱项。放弃。

**离线T+1跑批**：每天凌晨汇总前一天数据到统计表，但运营要看"今日实时GMV"，T+1满足不了实时性。放弃。

**ClickHouse/StarRocks这类OLAP引擎**：性能确实猛，但为了一个后台统计页面就上新中间件，运维成本和数据同步复杂度都上去了，我们团队小，扛不起。搁置。

**Redis预聚合**：订单创建、支付、取消、退款时，顺手把对应维度的计数器在Redis里加一。查询端直接读计数器，毫秒级返回。缺点是Redis挂了数据会丢，需要补偿。

最终选的是**Redis预聚合+MySQL兜底**的组合架构：

- MySQL作为唯一数据源，订单可靠落库，任何时候都能重建Redis里的统计
- Redis作为加速层，所有实时统计走预聚合计数器，查询只读Redis
- 每天凌晨定时全量重建，用MySQL重算指标刷新Redis
- 对账任务周期对比MySQL和Redis值，偏差过大自动重建

"实时增量为主，全量重建兜底"。既拿到Redis的毫秒级响应，又不至于Redis一挂统计就瘫痪。

## Key设计：预聚合成也Key败也Key

做Redis预聚合，Key设计是灵魂。随手写死一个字符串，后期维度一加你就崩。

我用的规则：`stat:order:{维度标识}:{维度值}:{指标名}:{时间粒度}:{时间值}`。

举个例子，"2026年10月18日app渠道已支付订单"的Key：

`stat:order:channel:app:status:paid:cnt:day:20261018`\
`stat:order:channel:app:status:paid:gmv:day:20261018`

为什么把指标名（cnt/gmv/refund_cnt）也拼进去？因为不同指标数据类型不一样——计数用INCR，金额用INCRBYFLOAT。拆成独立Key，写的时候互不影响，读的时候一次mget就行。

时间粒度做了三层：day、hour、minute。天报表按day，实时大屏看minute。小时和天粒度靠定时任务从分钟粒度roll up。

一个必踩的坑：**维度枚举一定要预先收敛，不能让用户随便传值当Key后缀**。恶意请求传个随机字符串当channel，Redis瞬间多出几十万个无用Key，内存直接爆。我在代码里做了白名单校验，不在枚举里的维度直接拒绝。

## 核心实现：双写没你想的简单

关键动作就是在订单状态变更节点——创建、支付、取消、退款——同步更新Redis计数器。

听着就是几个INCR？没那么简单。

**第一个坑：计数一定要幂等。** 支付回调可能重复投递，MQ也可能重复消费。每次收到"已支付"都INCR，重复消费一次就多算一笔。我基于订单ID做去重：已处理过的订单ID存入Redis SET，处理前先判断。SET只保留最近7天ID，内存可控。

**第二个坑：增减要成对。** 订单从"待支付"变"已支付"，要给paid_cnt加一、unpaid_cnt减一。最开始只加不减，待支付数量一直涨，数据一塌糊涂。后来抽象通用方法，传入旧状态和新状态自动算加减，业务代码只管调。

**第三个坑：浮点数精度。** GMV用INCRBYFLOAT累加，多次累加后可能出现19.990000000000002这种尾差。读取时统一用BigDecimal做ROUND_HALF_UP保留两位小数即可。

核心增量逻辑（伪代码）：

`public void onOrderStatusChange(OrderEvent event) {`\
`    // 1. 幂等去重`\
`    String dedupKey = "stat:order:dedup:" + event.getOrderId();`\
`    Boolean isNew = redisTemplate.opsForValue()`\
`        .setIfAbsent(dedupKey, "1", 7, TimeUnit.DAYS);`\
`    if (Boolean.FALSE.equals(isNew)) return;`\
\
`    // 2. 旧状态减一，新状态加一`\
`    String day = DateUtil.format(event.getOccurTime(), "yyyyMMdd");`\
`    updateCounter(event, event.getOldStatus(), -1, day);`\
`    updateCounter(event, event.getNewStatus(),  1, day);`\
`}`\
\
`private void updateCounter(OrderEvent e, int status, int delta, String day) {`\
`    String cntKey = String.format(`\
`        "stat:order:channel:%s:status:%d:cnt:day:%s",`\
`        e.getChannel(), status, day);`\
`    redisTemplate.opsForValue().increment(cntKey, delta);`\
`    if (status == OrderStatus.PAID.getCode()) {`\
`        String gmvKey = String.format(`\
`            "stat:order:channel:%s:gmv:day:%s", e.getChannel(), day);`\
`        redisTemplate.opsForValue()`\
`            .increment(gmvKey, delta * e.getAmount().doubleValue());`\
`    }`\
`}`

代码不复杂，关键是所有状态流转入口都要调到，漏一个数据就歪。

## 深分页顺手也治了

原接口除了统计慢，分页明细也慢。`LIMIT 100000, 20` 这种写法，MySQL先扫10万行扔掉再取20行，越往后越慢。运营导出数据翻到几千页是常事。

我用**游标分页**替换offset分页。前端不传pageNo，传上一页最后一条记录的id，WHERE改成：

`WHERE id < #{lastId} ORDER BY id DESC LIMIT 20`

每次走主键索引，从lastId往后扫20行就完事，翻到第100页和第1页速度一样。缺点是不能跳转到任意页，但运营后台"上一页/下一页"完全够用，这个取舍值得。

## 兜底：Redis不能成单点

缓存方案最怕什么？Redis挂了，或者某个计数器bug算错了你没发现，运营拿着错数据开周会，那就是生产事故。

做了三层兜底：

**本地Caffeine二级缓存**：每个统计Key在应用本地缓存10秒。Redis真挂了，10秒内的请求还能顶着，给你留熔断反应时间。

**全量重建任务**：每天凌晨2点跑任务，用MySQL把前一天所有维度的统计值重算一遍覆盖Redis。相当于每天对一次账，把MQ丢失、服务重启、主从切换等偏差修正掉。

**实时对账监控**：每15分钟随机抽几个维度，用MySQL实时count和Redis对比。偏差超1%就告警并自动重建该维度。这样就算漏了双写，15分钟内就能发现。

上线后对账跑了一周，最大偏差0.3%，原因是个边界case：订单23:59:59创建、00:00:03支付跨天了。后来把时间维度按业务发生时间取、而非事件处理时间取，就修好了。

## 最终效果

上线一周后的数据：

- P99耗时：2.8秒 → 32毫秒，提升约87倍
- 高峰期P99：4.2秒 → 48毫秒
- MySQL统计类慢SQL：每天几百条 → 清零
- Redis预聚合Key总内存：不到20MB
- 运营投诉：零。还有运营特意跑过来问"是不是换服务器了，怎么突然这么快"

## 最后几个提醒

**预聚合不是银弹。** 维度组合爆炸时（几十个维度任意组合），Key数量会呈笛卡尔积增长，Redis内存可能扛不住。这种场景要么上OLAP，要么只预聚合TOP N高频维度组合，剩下的回源。我这次维度不多（渠道5个、状态6个、分类10个出头），组合数可控才敢这么干。

**别在事务里写Redis。** 最开始我把Redis更新放在MySQL事务提交前，结果事务回滚了，Redis已经加一，数据对不上。正确做法是在事务commit成功后的回调里发MQ，由消费者异步更新Redis。

**计数器用String不用Hash。** 一开始图省事想把同一天所有维度塞进一个Hash，HINCRBY一把搞定。后来发现Hash在field多时会触发rehash，单次操作耗时陡增，也没法单独给某个field设过期时间。拆成独立String Key，性能稳，过期也好控制。

**过期时间要设对。** 天粒度Key设90天过期，够运营查季度数据；分钟粒度只设3天过期，不然内存越积越多。别图省事全设永久，跑半年Redis就满了。

## 写在最后

这次优化最大的感受：性能问题到了一定阶段，拼的已经不是SQL调优技巧了，而是**你愿不愿意换个思路**。

遇到慢查询，很多人第一反应是EXPLAIN、加索引、改SQL。这些都没错，但如果数据量和查询模式本身超出了MySQL的舒适区，在SQL层面再怎么抠，收益也是线性的。换一个更适合的组件或组合，收益是数量级的。

但也别为了炫技上一堆花里胡哨的中间件。上ClickHouse、上Flink做实时数仓当然也行，那是杀鸡用牛刀。Redis+MySQL这套组合，两个人周改完，线上跑了两个月稳如老狗，这就够了。

技术选型从来不是选最牛的，是选最合适的。

你们线上有没有遇到过那种"怎么调都调不快"的接口？最后用什么方案解决的？评论区聊聊，我攒着下次写。


运营后台的订单统计页，P99耗时稳定在2.8秒，高峰期冲到4秒开外。运营点个"今日GMV"要转圈半天，老板看数据大屏卡了一次，直接在群里@技术，问是不是服务器没续费。

百万订单统计从3秒压到30毫秒，我是怎么一步步把慢接口救回来的

微服务, spring cloud, spring boot, java, 教程, springcloud alibaba, nacos, sentinel, seata, 后端开发

人工智能

将订单统计接口从2.8秒优化至30毫秒，核心是摒弃MySQL实时聚合，采用Redis预聚合计数器方案，配合幂等去重、状态增减、游标分页及每日全量重建兜底，实现高性能与数据一致性。

数据同步

中间件

数据库

服务器

MySQL

Redis

OLAP

2026上云采购 | AI焕新·智启新局

tchousec

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

百万订单统计从3秒压到30毫秒，我是怎么一步步把慢接口救回来的-腾讯云开发者社区-腾讯云

百万订单统计从3秒压到30毫秒，我是怎么一步步把慢接口救回来的

百万订单统计从3秒压到30毫秒，我是怎么一步步把慢接口救回来的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐