一个不可思议的MySQL慢查分析与解决

经由过程以膳绫侨芽，我们可以发明如下几点问题：

经由过程 biz_date 预估出来的行数和 biz_date + status=2 预估出来的行数几乎一样，为 98w。

大年夜家应当都据说过要选择性好的字段放在组合索引的最前面?

实际萌芽表 biz_date + status=2 一笔记录都没有。

整表数据量达到了99万，MySQL 发明经由过程索引扫描须要98w行(预估)

是以，MySQL 经由过程统计信息预估的时刻，发明须要扫描的索引行数几乎占到了全部表，放弃了应用索引，选择了走全表扫描。

那是不是他的统计信罕见问题呢?我们从新收集了下表统计信息，发明履行筹划的预估行数照样一样，猜测只能根据组合索引的第一个字段进行预估(待肯定)

mysql > select * from testtable WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;
Empty set (0.79 sec)
mysql > select * from testtable force index(idx_bizdate_st) WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;
Empty set (0.16 sec)

我们发明，强迫指定索引后，萌芽耗时和没有强迫索引比较，切实其实履行速度快了很多，因为没有强迫索引是全表扫描嘛!然则!依然异常慢!

那，能不克不及让他不要扫描索引的那么多范围呢?之前的索引模型中也说过，MySQL 是经由过程索引去肯定一个扫描范围，如不雅可以或许定位到尽可能小典范围，那是不是速度上会快很多呢?

并且营业逻辑上是按期删除必定日期之前的数据。所以逻辑上来说，每次删除都是只删除一天的数据，直接让 SQL 扫描一天典范围。那么我们就可以改写 SQL 啦!

mysql > select  *  from  testtable WHERE biz_date >=  '2017-08-20 00:00:00' and  biz_date <= '2017-08-21 00:00:00' and  status =  ; 
Empty set ( 0.00  sec) 
mysql > desc  select  *  from  testtable WHERE biz_date >= '2017-08-20 00:00:00' and  biz_date <=  2017-08-21 00:00:00' and  status =  2 ; 
+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+ 
| id | select_type | table            | type  | possible_keys  | key            | key_len |  ref   | rows |  Extra              | 
	
			 4/5   首页 上一页 2 3 4 5 下一页 尾页	
			

　　推荐阅读
　　“互联网+”经济模式对民商事审判的影响与应对
            党的十九大年夜申报提出，在深化供给侧构造性改革中，推动互联网、大年夜数据、人工智能和实体经济深度融合。是以，为赓续加强经济立异力和竞争力，我国经济体系体例中“互联网+”经济模式将>>>详细阅读


本文标题：一个不可思议的MySQL慢查分析与解决
地址：http://www.17bianji.com/lsqh/38638.html
 1/2    1