查询慢问题解决方案

查询慢问题解决方案

比如在我们项目里一个表的数据量很大的时候，创建时间建索引，统计数量时，查询7天的数据，如果加其他无索引的条件，例如 status=1的时候，耗时巨大。

分析：

此表在相同时间段内，插入的数据不平均，导致时间索引在整个时间内不均衡，即如上在查询7天数据的时候，查询出1月10-1月17的数量为700w+,1月20-1月27的数据为200w+,这样在加入条件status=1后，扫描行数即为10-17的为700w+，即耗时时间为暴增。一次来看是用创建时间的索引来增加查询效率并不理想。
此查询主要分为3类：一类为用户自己查询，一类为后台查询，最后一类为自动匹配查询。
最后一类有联和索引可以忽略。用户自己查询和后台查询存在相同问题。用户自己查询会走用户id的关联索引，但是用户id不是最优索引。即用户自己查询和后台查询相同，在查询的时候分为两类，一种是无高效率索引字段查询（可看做无条件查询），一种是有高效索引字段查询。在有高效索引字段查询的时候，查询效率很高，此中情况忽略。在无高效索引字段查询的时候，会存在查询慢的问题。此查询拆分两条sql,一条 取列表数据 有limit限制，即查询时间较短，另一条为查询数量的sql(此sql需要获取总数量，在存在无索引字段的时候查询时间较长（status=1）)，即可得出在分页查询的时候查询总数的时候慢（select count(*) …）。

解决方案：

实现统计数据量，每个用户有效数据，无效数据，总数据以及所有数据的有效数据，无效数据。查询数量的时候可以取这些统计的数量，即用户查询的时候取对应用户的有效数，后台查询的时候取所有数据的有效数。即在前端来看查询结果一样，也有对应的分页，效率较高，目前数据来看会在1秒以内，而之前逻辑为15秒外。
第一条sql优化，在使用上述解决方案的时候，第一条sql在查询较大页数的时候会存在效率问题，此可以查看limit的原理。例如：limit 5000000,100的意思扫描满足条件的5000100行，扔掉前面的500w行，返回最后的100行，当然慢了。此sql优化方案。优化，在不存在status=1的情况下，只取id,50w数据的时间为160±ms,在500w的时候为1.6±s,即只能保证在5w也每页10条的效率。取值先只取id的效率比取*的效率高，秒内相差10倍。
1，50w 1632ms,500w 15975ms
select * from goods_info limit 5000000,10;
2，50w 80ms,500w 788ms
SELECT * FROM goods_info a WHERE a.id >= (select b.id from goods_info b limit 5000000, 1) limit 10;
3，50w 82m,500w 786ms
SELECT * FROM goods_info a JOIN (select id from goods_info limit 5000000, 10) b ON a.id = b.id;