接口响应优化方案

3 篇文章 0 订阅

        最近收到客户反映系统卡顿严重,然后让他截图看了下,最长响应时长居然高达16s,其他3s,4s的接口一大堆,简直是恐怖!

          简单来说,这个耗时16s的接口其实是统计一张历史数据表里的数据,这张表大概有三百多万条数据,日增长1万左右,因为客户要求最多留存2年,所以也不必考虑分表了。

        看了下查询逻辑,其实也比较简单,就是根据两个字段去数据库里筛选,但是查询出来的数据量比较大,所以不管怎么优化都效果不好;然后我注意到该表使用innoDb存储引擎,考虑到历史数据表查多写少,是不是用Myisam存储更好?想到就做,先导出表结构和数据,直接在sql里修改表引擎,再重新刷一遍。最后在页面上刷新接口,居然只需要1s多就返回了!犀利!

        然后其他接口慢大概就是一些比较低级的问题了:

       1. 大表查询不加索引

       2. 多表关联查询甚至3张,4张表一起join(我只想说这种人真是懒到家了)

       3. 一个接口封装了好几个方法,有些方法已经查询过的数据,其他方法又查了一遍

       4. 返回树结构数据时直接在mybatis的xml里递归查询(懒!)       

       5.  一些字段包含大量content文本,一股脑用select * 捞出来

       6.  在java循环里查询数据库(懒)

       7.   时间范围查询不走索引,可以使用时间戳代替

       8.  用大表去驱动小表查询效率低(有个最简单的写法,不要用join on,直接逗号去隔开就行了,让mysql去自行判断)

     

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值