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

写在前面

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

什么是预计算?

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

预计算在报表场景的实践

背景

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

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

举个例子

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

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

不足之处

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

究其本质

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

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

写在最后

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

相关推荐
鹏程十八少25 分钟前
Android TransactionTooLargeException 的真相与修复:从 1.13MB Bundle 到 Binder 内核的完整剖析
前端·后端·面试
geovindu29 分钟前
go: Monitor Pattern
开发语言·后端·设计模式·golang·监控模式
ZHOUPUYU1 小时前
PHP 开发实战:从零搭建一个高性能的 RESTful API 服务
运维·开发语言·后端·html·php
身如柳絮随风扬1 小时前
除了 JWT,你还用过哪些认证方案?Spring Security 中如何集成 JWT?
java·后端·spring
techdashen1 小时前
Rust 能帮你捕获什么,又不能捕获什么
开发语言·后端·rust
YOU OU1 小时前
Spring MVC 练习项目
java·后端·spring
Spider Cat 蜘蛛猫10 小时前
Springboot SSO系统设计文档
java·spring boot·后端
zyk_computer12 小时前
AI 时代,或许 Rust 比 Python 更合适
人工智能·后端·python·ai·rust·ai编程·vibe coding
无心水12 小时前
【Hermes:进阶调优与性能优化】45、性能调优:降低延迟与 token 消耗的 7 个技巧 —— 让 Hermes 智能体跑得更快、花得更少
网络·性能优化·mcp协议·openclaw·养龙虾·hermes·honcho
雨辰AI12 小时前
SpringBoot3 项目国产化改造完整流程|从 MySQL 到人大金仓落地
java·数据库·后端·mysql·政务