设备管理优化

1、前提

项目中，设备管理模块查询速度缓慢，以球阀为例。平均查询时间约为一根烟左右。比较缓慢，难于接受。

2、整理代码思路

（1）定位速度变慢的原因

（2）根据原因分析相应的处理方法

（3）实践测试效果

代码思路简介

1、查询出主表数据，主表字段数据。（根据每页展示数据不同而波动）

2、循环通过关系表查找对应的字表字段和对应的数据信息。

原本的拼接逻辑

3、循环拼接成一条数据。

assetSpecList.size()>0&&dmClassspec.getAssetattrid().equals(assetSpecList.get(j).getAssetattrid())&&entity.getEventid().equals(assetSpecList.get(j).getAsseteventid())

4、返回，展示。

简单测试后可以发现List assetSpecList = this.dmAssetspecDao.getAssetAttrs(entity.getClassstructureid(), null, null,null);这一条查询语句时间较长，经过读代码的分析，他的作用是查询出所有满足条件entity.getClassstructureid()的字表数据，然后根据所需要的50条数据的id筛选所需要的拼接数据。

注意！在没有十分把握之前，优化的同时尽量减少对原有代码逻辑破坏。

优化思路

我们看这个条件，考虑从这个条件入手

assetSpecList.size()>0&&dmClassspec.getAssetattrid().equals(assetSpecList.get(j).getAssetattrid())&&entity.getEventid().equals(assetSpecList.get(j).getAsseteventid())

（1）将这个查询所有的语句从循环体里，拿到循环体外。避免重复多次的访问数据库进行查询。

（2）避免查询出所有的数据，尝试只查询出我们需要的50条数据相关数据再进行业务拼接。

两种优化方案分别做了一套，都达到了优化的效果但各有优缺点。

注释掉部分为第一种优化方案，采用的为第二种

（1）针对第一种，缺点：所有数据依旧全部查询，数据包会随着数据的增加日益庞大，效率也会倍率下降。虽然避免了循环体内的查询数据，在数据量小范围内尚可，数据量变大，问题依然会暴露。

（2）针对第二种，缺点：查询仍在循环体内未提出，单条查询速度尚可，循环后不论数据量大小，均会将效率延长。

所以说两种代码均有继续优化的空间，但可能就需要破坏代码逻辑。需要进一步解读业务和具体的代码逻辑，理清所有的功能思路和实现方式才能下手优化。