线上查询接口性能优化

订单工序组件的物料供应商笛卡尔积列表-QM

http://xxx/v1/2/me-wip-components/component-material/list/supplier
请求参数:
qo:WipComponentQo(wipOrderNo=880006461176, wipOperationId=null, keyword=null, materialDescPre=null)

接口需求:

查询该订单号下的主机物料+组件订单,并返回他们的物料名称和供应商编号名称.
这个需求数据源来源:
me微服务下存储了订单/工序/工序组件(组件物料)
model微服务下存储了物料编号/物料名称/物料供应商编号/物料供应商名称.
因此,要查me+model两个部分.

线上查询性能问题:

当前订单存在2000+组件物料
排查录:
工厂:xxxx
订单:xxx
接口:订单工序组件的物料供应商笛卡尔积列表-QM
http://xxx/v1/2/me-wip-components/component-material/list/supplier
请求参数:
qo:WipComponentQo(wipOrderNo=880006461176, wipOperationId=null, keyword=null, materialDescPre=null) pageRequest:io.choerodon.mybatis.pagehelper.domain.PageRequest@7e432d39 tenantId:2
响应:
返回了2336条物料记录.
生产报错就是因为请求的数据量过大超过了请求的报文最大负载能力,被系统安全机制给拦截报错.
解决办法:
缩小分页的范围,每页20条,默认返回第一页.优化查询算法,先查订单要分页获取,再查物料名称,再查供应商.

该接口经历3个版本的更新

版本1:

me的订单 left join model的物料 left join供应商.实现关联查询.–因物料数据巨大(10w+),连接查询性能异常缓慢

版本2:

增加了内协订单号的关联查询,使用or 关键字,将物料拆出来一个单独查询语句.–主机表一次,工序组件表一次,物料表一次,供应商表一次,
查询了4次数据库,在程序中对结果集进行组装绑定到对象列表.

版本3:

就是本次的版本修订,因组件物料超过2000+,一次返回导致数据流被截断,应用程序报错了,只是在返回物料较多时报错.采取分页,最大页宽为20条一次,于是将物料数量截断,再拼接物料名称和供应商名称.

总结:

针对那些请求比较频繁,查询数据量大的接口性能优化.有3种常用的优化方法.
1.将结果cache到redis里,迅速返回.
2.如果打到数据库上,不要进行join查询和or查询,而是要单表查询后将结果在内存中组装出来.
3.一定要控制记录的返回条数,在接口设计时,就要分页返回,对页宽做限制.