根据业务实现逻辑优化查询 - 案例(一)

需求如图：查询不同类型公司家数、总公司家数；新增加不同类型公司家数、总公司家数；

程序采用：springmvc + mybatis +MySQL

 

期初，在xml文件中配置了一条多条件查询的对公司id进行distinct求count的SQL语句，返回一个String类型的值，适应不同条件的查询，在控制层读取6次数据封装到map集合中返回。前端采用jQuery+ajax异步读取赋值到jsp页面。

 

效率：从打开页面到数据显示超过24秒。慢的要死。

用navicat连接数据库后，测试单条SQL执行效率，多次执行，测试结果：平均4.2秒，视图里面不过3200多条数据。

由于我没有足够权限，不知道服务器配置，也不知道，源库什么样子，我只有读取视图的权限，只能想别的办法。

 

咨询了同事，针对类似的单指标多次查询的情况，有采用union all 进行查询（union 会去重）。这种方式经过测试，没什么卵用，总用时还是24秒多。

然后又测试了count(1)、count(*)，结果没有任何惊喜。

同事提出了多线程取数据的方案：每个线程发出一个SQL请求，最后将数据合并。这种方案肯定行，但我没有尝试，觉得有点用大炮轰蚊子的感觉。

 

第二天，咨询了开发组长：

首先：组长看了我的SQL后，普通的count ，SQL很简单，没啥好优化的。

然后：看了navicat的SQL的剖析结构，显示Sending data 占83%。这表名数据传输占据了绝大部分的时间，而不是SQL的执行时间。这种情况我们无能为力。

接下来：组长审视了一下这6项指标，告诉我，单条SQL不能优化，但可以减少查询次数：

对分层类型字段进行分组查询，总数=各分组数量之和。全部和新增各查询一次即可。

果然好，6次查询减少到2次查询。这意味着：原先的24秒，将变成8秒。

 

再后来，我在写代码过程中，又发现可以优化的一项措施。

在工作中，我们习惯于将所有结果，全部封装到一个集合中，一次性返回给前端。这当然是个好习惯，但有时适当拆解会更好。

这里下面的三个指标的查询，仅仅是比第一排多了一个条件：时间。

所以我将service层代码增加一个参数queryType：参数为all时查询全部，参数为new时查询新增。这样service层代码瞬间减少近40%的代码。

惊喜的在后面，前端采用ajax异步加载，所有的开发语言都是顺序执行的，但ajax不同，熟悉ajax的应该清楚，ajax里面的代码，不影响该方法后面的js代码执行。也就是说，如果当前js函数是ajax执行，它不会对后面的js函数造成阻塞。

这样，我就可以用js函数以不同的参数同时请求后端controller。如此，上面预期的8秒，就变成了了4秒。

所以，优化SQL之前，先想想自己的实现逻辑是否最优方式。

 

最终，上线时，又由数据组增加索引，保证查询速度。