性能优化利器——预计算(含报表场景实践)

写在前面

很多人觉得工作像是无尽的CRUD,实际上工作场景中包含很多值得思考的可以性能优化的点。针对数据而言,比较常见的性能优化方式有两种,一种是 cache, 一种是预计算。本篇文章会介绍后者。

什么是预计算?

预计算和cache一样,都是在用空间换时间,顾名思义,将计算提前到更早的阶段(比如数据导入阶段),可以减少查询时的耗时与成本。

预计算在报表场景的实践

背景

报表是一个常见的业务场景,为了展示不同纬度的业务数据,我们需要在一个页面中展示不同维度不同展现形式的的报表。从技术角度,前端页面会同时发送多个请求至服务器,并接受服务器返回的结果。

以工单系统为例,我们可能需要查看一定时间内工单相关的数据(比如成功率、发起工单数),以及一定时间内用户相关的数据(比如每日使用次数、新增用户/留存率),假如这些数据存在一张表中,那我们可能会根据请求数据的不同编写不同的sql。

举个例子

然而同一时间的多个sql必然会带来耗时的增加,既然数据存在于一张表中,那是否可以只查询一次拿取所有需要的数据呢?

如图,通过一次性查询结果并根据请求的需要进行初步的计算再返回给浏览器,这样的好处是减少了因SQL查询而导致的网络传输的次数(网络传输向来是查询数据场景中耗时的大头)

不足之处

这里面有一个漏洞,就是多个请求其实是同时发送,那么让多个请求等待一次网络请求的结果本身也是一个耗时点,在第一个请求抢锁并查询数据的时间里,其他的请求其实都是阻塞等待的,而其他的请求不断的轮询本身也会造成CPU资源的挤占,需要根据场景设计等待时间

究其本质

前面说了,预计算和cache一样,都是在用空间换时间

如果我们在数据导入阶段就计算出不同的用户数据,那么虽然多个sql会增加网络传输耗时,但无论是DB还是Server的计算消耗却都没有了

写在最后

两种思路我觉得都有可取之处,有趣的是,究竞哪个思路查询更快并不是一个静止的答案,而是需要综合考虑自己的报表个数,查询数据量级等多个条件。

相关推荐
devlei1 小时前
从源码泄露看AI Agent未来:深度对比Claude Code原生实现与OpenClaw开源方案
android·前端·后端
努力的小郑3 小时前
Canal 不难,难的是用好:从接入到治理
后端·mysql·性能优化
Victor3564 小时前
MongoDB(87)如何使用GridFS?
后端
Victor3564 小时前
MongoDB(88)如何进行数据迁移?
后端
小红的布丁4 小时前
单线程 Redis 的高性能之道
redis·后端
GetcharZp4 小时前
Go 语言只能写后端?这款 2D 游戏引擎刷新你的认知!
后端
宁瑶琴6 小时前
COBOL语言的云计算
开发语言·后端·golang
普通网友6 小时前
阿里云国际版服务器,真的是学生党的性价比之选吗?
后端·python·阿里云·flask·云计算
IT_陈寒7 小时前
Vue的这个响应式问题,坑了我整整两小时
前端·人工智能·后端
Soofjan7 小时前
Go 内存回收-GC 源码1-触发与阶段
后端