查询性能优化

本文分享了在保险业务中,面对多被保人多险种查询耗时问题的性能优化过程。通过jmeter压测发现查询接口响应慢,使用jprofiler定位问题在于抄单操作。优化措施包括:加入分库分表键作为查询条件,添加和优化索引,减少索引扫描行数与返回行数的不一致,调整SQL查询方式减少数据库交互,以及限制返回字段以降低数据量。经过优化,20并发情况下查询时间从13s降低到113ms。
摘要由CSDN通过智能技术生成
背景说明:

业务是保险的业务,分享一篇查询性能优化的文章。本人目前负责的出单业务和业务介入等模块。

为何做这个查询的性能优化?
  • 由于产品升级,多被保人多险种多责任的出单,一个关系单下多个被保人的保单查询耗时多
  • 我们是以被保人的维度落的保单数据,也就是说一个关系单多个被保人多个险种,那么一条保单会对应多个险种数据,其次还有责任,特约,被保人的数据等,导致查询耗时很慢
  • 保全服务调用保单接口易出现超时现象,同时查询19个被保人数据。
如何发现这个查询慢?
  • 使用jmeter工具对单个接口进行压测,优化前20并发一个关系单19个被保人持续10分钟压测,平均耗时13s
  • 使用jprofiler,监测到做保全项时,抄单这块耗时多。
如何做这个查询性能优化?
  • 我们业务库是采用分库分表策略,所以你的查询sql你可以检查一下查询条件,是否将分库分表键当作了查询条件,如果没有,麻烦加上分库分表键这个查询条件
  • 检查你的查询sql,是否利用到了索引,如果没有走索引,麻烦加一下索引,在需要且必须的字段上增加索引
  • 使用explain来检查你的sql和你加的索引,索引类型有很多中,可以去官方文档或者上网搜一下,最好让你的查询走的索引是效率更高效的,同时也要注意一下索引最好不要
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值