一个奇怪的MySQL慢查询，打懵了一群不懂业务的DBA！

前言

最近，开发人员须要按期的删除表里必定时间之前的数据，SQL以下： mysql > delete from testtable WHERE biz_date <= '2017-08-21 00:00:00' AND status = 2 limit 500\G 前段时间在优化的时候，咱们已经在相应的查询条件上加上了索引，以下： KEY idx_bizdate_st (biz_date,status) 可是实际执行的SQL依然很是慢，为何呢，咱们来一步步分析验证下。

分析

表上的字段既然都有索引，那么按照以前的文章分析，是两个字段均可以走上索引的。

既然可以利用索引，表的总大小也就是200M左右，那么为何造成了慢查呢？

咱们查看执行计划，去掉limit 后，发现他选择了走全表扫描。

mysql > desc  select * from testtable   WHERE biz_date <= '2017-08-21 00:00:00';
+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+
| id | select_type | table     | type | possible_keys  | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | testtable | ALL  | idx_bizdate_st | NULL | NULL    | NULL | 980626 | Using where |
+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+
1 row in set (0.00 sec)

-- 只查询biz_date
-- 关键点：rows:980626;type:ALL

mysql > desc  select * from testtable   WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;
+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+
| id | select_type | table     | type | possible_keys  | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | testtable | ALL  | idx_bizdate_st | NULL | NULL    | NULL | 980632 | Using where |
+----+-------------+-----------+------+----------------+------+---------+------+--------+-------------+
1 row in set (0.00 sec)

-- 查询biz_date + status 
-- 关键点：rows:980632;type:ALL

mysql > desc  select * from testtable   WHERE biz_date <= '2017-08-21 00:00:00' and status = 2 limit 100;
+----+-------------+-----------+-------+----------------+----------------+---------+------+--------+-----------------------+
| id | select_type | table     | type  | possible_keys  | key            | key_len | ref  | rows   | Extra                 |
+----+-------------+-----------+-------+----------------+----------------+---------+------+--------+-----------------------+
|  1 | SIMPLE      | testtable | range | idx_bizdate_st | idx_bizdate_st | 6       | NULL | 490319 | Using index condition |
+----+-------------+-----------+-------+----------------+----------------+---------+------+--------+-----------------------+
1 row in set (0.00 sec)

-- 查询biz_date + status+ limit 
-- 关键点：rows:490319;

mysql > select count(*)  from testtable   WHERE biz_date <= '2017-08-21 00:00:00' and status = 2;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.34 sec)

mysql > select count(*)  from testtable   WHERE biz_date <= '2017-08-21 00:00:00';
+----------+
| count(*) |
+----------+
|   970183 |
+----------+
1 row in set (0.33 sec)

mysql > select count(*)  from testtable;
+----------+
| count(*) |
+----------+
|   991421 |
+----------+
1 row in set (0.19 sec)

mysql > select distinct biz_status from testtable;
+------------+
| biz_status |
+------------+
|          1 |
|          2 |
|          4 |
+------------+
复制代码

经过以上查询，咱们能够发现以下几点问题：

经过 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)
复制代码

咱们发现，强制指定索引后，查询耗时和没有强制索引比较，的确执行速度快了不少，由于没有强制索引是全表扫描嘛！可是！依然很是慢！

那么还有什么办法去优化这个原本应该很快的查询呢？

你们应该都据说过要选择性好的字段放在组合索引的最前面？

选择性好的索引在前面并非对全部的场景都通用的，这个场景能够将status放前面，sql速度会更快。

那，能不能让他不要扫描索引的那么多范围呢？以前的索引模型中也说过，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 = 2;
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                 |
+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+
|  1 | SIMPLE      | testtable        | range | idx_bizdate_st | idx_bizdate_st | 6       | NULL |  789 | Using index condition |
+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+
1 row in set (0.00 sec)

-- rows下降了不少，乖乖的走了索引

mysql > desc select * from testtable WHERE biz_date >= '2017-08-20 00:00:00' and biz_date <= '2017-08-21 00:00:00' ;
+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+
| id | select_type | table            | type  | possible_keys  | key            | key_len | ref  | rows | Extra                 |
+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+
|  1 | SIMPLE      | testtable        | range | idx_bizdate_st | idx_bizdate_st | 5       | NULL | 1318 | Using index condition |
+----+-------------+------------------+-------+----------------+----------------+---------+------+------+-----------------------+
1 row in set (0.00 sec)

-- 即便没有status，也是确定走索引啦
复制代码

小结

这个问题，我本来打算用hint，强制让他走索引，可是实际上强制走索引的执行时间并不能带来满意的效果。结合业务逻辑，来优化SQL，是最好的方式，也是终极法宝，必定要好好利用。不了解业务的DBA，不是一个好DBA...