性能优化总结(三)一对多join的级联查询

本文介绍了在优化一个运行4年的老项目时,面对一对多级联查询导致的性能问题,通过拆分SQL和调整数据处理方式,有效减少了CPU使用率和响应时间。在不改变前端的情况下,通过减少循环和利用HashMap优化数据合并,使得API在性能测试中达到8000r/m的目标,但CPU仍是瓶颈,未来考虑去除TypeHandler进一步优化。
摘要由CSDN通过智能技术生成

最近在对一个已经运行了4年的老项目进行性能优化,这是一个app,我主要还是从后台优化。这个项目后台提供的API并不多,只有十几个,但是性能非常差。有些API连每分钟2000的request都扛不住,虽然后台的并发node已经增加到8个。一看代码就知道为什么了,原来这些API都需要返回很多的数据,而且是级联的数据,就像你要获得一个“军”的数据,“军”下面又有“师”,然后是旅团营连排,这样的树状结构,大概有5层,而且是一对多的关系。原来的代码中是先获得第一层的数据,再循环获得下面的第二层,然后是循环获得第三层,依次类推。这样带来了很多的数据库访问和循环操作。结果就是这个API不仅慢而且非常耗CPU。

一开始看到这样的结构,我是排斥的。。。。一对多如果写SQL来join的话,就会join出很多的数据来,因为毕竟是相乘的关系。之前就有这种SQL把服务整挂的经验,当时的情景是用用户表去join电话表,地址表,eamil表等,一个人可以有多个电话,地址,email。。。所以是一对多的关系,想要一下子全都拿出来,结果在测试环境中测试人员一直往同一个用户下面加地址,电话等,结果就是这个人有几百个地址,几百个电话。。。。最后join出几百万条数据,hibernate搞不定这个数据量。

回到这次的问题,怎么办,这个是比那个更多的join。首先数据量如果不大的话,我把它写成一个sql,用很多的join应该是没有关系的。于是去找了公司的DBE一块商量,DBE说先用这样的方式试一下。于是我开始写SQL,join了七八张表,用MyBatis。开始的自己测试的时候发现还可以,给性能测试一跑就完了,刚开始跑几分

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值