接口响应优化，sql优化实战

接口响应速度达到20s

前端展示接口平均速度为8s，最坏情况到达20s

默认搜索条件十分复杂，基本每个字段都传条件，不好建立联合索引

多线程异步查询

接口内容分为两部分，并且查询相互独立
1、查询页面集合（方法内存在很多业务逻辑，不是简单查询）
2、查询总数 （方法内存在很多业务逻辑，不是简单查询）
所以使用线程池来执行查询操作，这里使用Callable接口，Callable对象执行后可以有返回值，运行Callable任务可以得到一个Future对象，通过Future对象可以了解任务执行情况，可以使用future.get()方法等待线程的执行结果。（这里也可以使用CountDownLanch）

成功解决？

本以为到这里简单处理一下，就可以达到需求方可以接受的层度，自测接口一看
线程1耗时：6000ms
线程2耗时：7000ms
没办法只有梳理上百行的业务和sql（苦逼）！！！
一条一条的找到慢sql(这里还是精简后的sql，实际查询条件那叫一个眼花缭乱)

这里命名为：慢sqlA，执行耗时7s

SELECT COUNT(1) FROM ( 
SELECT COUNT(1) FROM `tb_product_information_pass` AS pass LEFT JOIN tb_product_contacts 
AS con ON con.product_information_id = pass.id LEFT JOIN tb_product_query_data pqd ON 
pqd.product_id = pass.id WHERE `product_status` = 1 AND pass.`show_id` != 1
 GROUP BY product_group_name ) AS t 

这里命名为：慢sqlB，执行耗时5s

SELECT COUNT(DISTINCT pass.id) AS `all`, 
SUM(IF(pass.`customer_rank` = '003003001', 1, 0)) AS `hide`, 
SUM(IF(pass.`customer_rank` = '003003002', 1, 0)) AS `toContact`, 
SUM(IF(pass.`customer_rank` = '003003003', 1, 0)) AS `setContact`, 
SUM(IF(pass.`customer_rank` = '003003004', 1, 0)) AS `cooperationed`, 
SUM(