结算账单生成的坑，我们是怎么从“性能地狱”爬回来的

大家好，我是小米，程序员一枚，今年刚好31岁(程序员的黄金年龄！)。今天这篇文章，我想跟你们聊聊一个我们项目上一直很头疼，但又不能不面对的“老大难”问题——结算账单的生成。

说实话，这个模块的“名声”在我们组一直挺响亮的，属于那种“提起来大家都懂”的类型。今天就来跟你们好好聊聊，我们是怎么一步步发现问题、挖坑、填坑，再爬出性能地狱的全过程的。

起因：一个“看似小事”的性能问题

还记得那是一个平平无奇的周一早晨，我刚打开电脑，企微上一串红色的@消息就跳了出来：

运营小李：@小米 结算页面又超时了……

产品经理大张：这都第几次了，能不能查查到底怎么回事？

我内心OS：“哎，又来了……”

其实这事已经不是第一次了。结算账单的生成一直是我们系统里“知名”的性能瓶颈。最早上线那会儿业务量还不大，几千条订单一跑，也能撑得住。

但随着功能越加越多，订单数据越积越厚，再加上每一代开发都“微调”过这个模块——这代码，早已不是最初那段清晰的小清新逻辑，而是一个巨大的意大利面。

• 你要说它代码丑？也不至于；
• 你要说它逻辑乱？还行；
• 可你要说它慢……那真的是慢！尤其一跑到上万订单的时候，十几秒、几十秒都不稀奇，有时还直接超时爆掉。

这让我不禁想到一句话：“技术债，不还就利滚利。”

排查：定位问题的过程

“慢”这件事，说容易也容易，说难也难。因为它不像报错有堆栈信息，一下就能精准命中，而是像那种“你觉得它不行，但它死活不告诉你哪里不行”。

于是，我开始了那天的深夜性能排查大冒险。

1. 抓日志

首先我加上了详细日志输出：从接收到请求开始，记录每一步的耗时，比如：

• 查询订单数据耗时
• 汇总金额耗时
• 调用外部接口耗时
• 数据转换耗时
• 写入账单表耗时

结果一看，最大耗时的地方在于订单数据查询！

2. 冷知识：我们订单存在MongoDB里

是的，我们不是用MySQL存订单，而是用了MongoDB。

刚开始选MongoDB，是因为灵活性强嘛，半结构化数据、快速开发、还能存嵌套结构，对于我们这种起初业务变化很快的系统来说，挺合适。

可问题也随之而来——MongoDB虽然查询灵活，但分页性能差，尤其是“深分页”。

这里插播一个冷知识：MongoDB在进行深分页(比如skip 100000)的时候，并不是“跳过”前面这么多数据，而是依然扫描了前面的数据，只是不返回而已。

想象一下你要拿出第10万个快递包裹，但你没有编号系统，只能一个个拆箱子找过去，前面99999个你都得看一眼。

这就解释了为啥我们查1万条订单还凑合，查十几万条就慢如蜗牛。

猜测与验证：是不是MongoDB的锅？

这时，我心里基本已经有了方向：“十有八九是MongoDB深分页导致的性能瓶颈。”

可做技术，不能凭感觉吃饭，一定要数据说话。

于是，我写了一个小脚本，对比了以下几种分页方式的性能：

结果一目了然：skip-limit 深分页几乎不可用，而基于 _id 游标的方式，性能提升极大！

优化方案：从skip-limit到游标分页

1、原来的分页逻辑(性能差)

这段代码里，skip(100000)是罪魁祸首。它会让MongoDB“挨个看过一遍”前面10万条，哪怕你只要后面100条。

2、新的分页逻辑(基于 _id 游标)

每次分页的时候，我们只需要记住上一次的 _id，下一次从它往后继续查即可。性能直接起飞！

延伸优化：再给它加点buff

虽然游标分页已经很香了，但我还是决定趁热打铁，把整个模块也一起梳理优化了一波：

1. 加缓存：结果可以缓存的就缓存，减少重复计算

比如一些中间过程计算结果、常量配置，甚至是一些汇总逻辑，我都加了本地缓存 + Redis二级缓存。

2. 拆查询逻辑：大批量拆小批量

原来是“一口气查完再处理”，现在改成“每页1000条，处理完再下一批”。分页处理、内存占用低、失败重试也方便。

3. 异步拆分：大订单走异步，不阻塞主流程

有些大客户订单量特别大，生成账单时间超长，直接拖慢整页响应。后来我把这种客户的处理拆成异步队列+回调提醒，用户点按钮后会看到“账单正在生成，稍后提醒”，极大减轻了主流程压力。

效果如何？用数据说话

优化上线后，我们做了一轮压测和实战观测：

不仅如此，运营和产品也终于不再“凌晨敲门”了，大家脸上的微笑也多了几分(笑)。

一点思考

说实话，这次优化让我感触颇深：

• 技术债不会消失，只会积累利息。
• 选型时的短期灵活，可能是未来的陷阱。
• 性能问题不怕有，怕没人去刨根问底。
• 工具用得再好，逻辑写得再优，数据量大了，一样卡

未来我们还会考虑：

• MongoDB + Elasticsearch 混合查询，部分维度可用 ES 来加速；
• 账单计算服务化、微服务拆分，增强弹性和可维护性；
• 加数据分析与指标观测，让性能问题“提前预警”。

END

你们有遇到过类似的MongoDB深分页性能问题吗？或者账单结算相关的“坑”？欢迎留言区交流～

我是小米，一个热爱代码和咖啡的程序员。如果你喜欢我这种边讲故事边聊技术的风格，记得关注我，下次继续带你吃瓜、踩坑、修Bug！

生活不止有Bug，还有优化后的清风与自由~

我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！