生产现象出现场景:统计查询效率低下超时
用户提出,想统计一下知识推荐量,有效推荐量,点击查看量;
初始操作:
于是用sql给了个简单统计,按月查询,在表上给sql中的条件字段加了索引,如下:
SELECT count(1) allCount from (select COUNT(1) from read_log_manage
where tenant_id = "TJBBT"
and begin_time > "2021-06-01 01:00:00"
and begin_time < "2021-06-31 23:59:59"
GROUP BY recall_id )a
6月的数据2万条,执行统计耗时 7.053秒,如下图;
7秒,太扯淡了,必须得优化啊,默认用户体验3秒超时
首先对sql进行分析优化:
(group by 与 distinct 不同场景下使用效果不同)
gourp by 作为子查询语句里的聚类,再去进行统计,
相似效果的有 distinct 去重统计,那便使用distinct试试效果,执行耗时为 3秒,
但是这也不行啊,一个去重统计要3秒,太扯了,但是sql已经优化了,索引也加了啊;
还能怎么优化?这个时候不能只看sql语句了,得看实际sql执行的情况:
常用 explain来查看sql执行的索引使用情况,使用explain后发现,sql语句一直都在使用索引辅助,并无不妥;
这个时候,(假如你没了解过InnoDB引擎的索引为什么能提升查询效率时)基本上没什么头绪了,
注意:InnoDB引擎的索引为B+Tree结构
B+树是大多数 MySQL 存储引擎的默认索引类型。因为不再需要进行全表扫描,只需要对树进行搜索即可,所以查找速度快很多。除了用于查找,还可以用于排序、分组、范围查找
注意:范围查找
这一点突然点醒了我,如果条件字段中某一字段的值大量相同,那就没必要加索引,如果加了索引反而加重了查找过程;
赶紧检查表字段,发现sql条件中tenant_id字段大量相同的值,尝试删除该字段索引后,执行sql,结果耗时 0.755秒;至此效率问题解决,sql的问题原因也明了!