SQL优化 · 经典案例 · 索引篇 - 数据库

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

Introduction

在这些年的工作之中，由于SQL问题导致的数据库故障层出不穷，下面将过去六年工作中遇到的SQL问题总结归类，还原问题原貌，给出分析问题思路和解决问题的方法，帮助用户在使用数据库的过程中能够少走一些弯路。总共包括四部分：索引篇，SQL改写篇，参数优化篇，优化器篇四部分，今天将介绍第一部分：索引篇。

索引问题是SQL问题中出现频率最高的，常见的索引问题包括：无索引，隐式转换。当数据库中出现访问表的SQL无索引导致全表扫描，如果表的数据量很大，扫描大量的数据，应用请求变慢占用数据库连接，连接堆积很快达到数据库的最大连接数设置，新的应用请求将会被拒绝导致故障发生。隐式转换是指SQL查询条件中的传入值与对应字段的数据定义不一致导致索引无法使用。常见隐士转换如字段的表结构定义为字符类型，但SQL传入值为数字；或者是字段定义collation为区分大小写，在多表关联的场景下，其表的关联字段大小写敏感定义各不相同。隐式转换会导致索引无法使用，进而出现上述慢SQL堆积数据库连接数跑满的情况。

无索引案例：

表结构

CREATE TABLE `user` (

……

mo bigint NOT NULL DEFAULT '' ,

KEY ind_mo (mo)

……

) ENGINE=InnoDB;

SELECT uid FROM `user` WHERE mo=13772556391 LIMIT 0,1

执行计划

mysql> explain  SELECT uid FROM `user` WHERE mo=13772556391 LIMIT 0,1;

           id: 1

  select_type: SIMPLE

        table: user

         type: ALL

possible_keys: NULL

          key: NULL

         rows: 707250

         Extra: Using where

从上面的SQL看到执行计划中ALL，代表了这条SQL执行计划是全表扫描，每次执行需要扫描707250行数据，这是非常消耗性能的，该如何进行优化？添加索引。
验证mo字段的过滤性

mysql> select count(*) from user where mo=13772556391;

|   0    |

可以看到mo字段的过滤性是非常高的，进一步验证可以通过select count(*) as all_count,count(distinct mo) as distinct_cnt from user，通对比 all_count和distinct_cnt这两个值进行对比，如果all_cnt和distinct_cnt相差甚多，则在mo字段上添加索引是非常有效的。

添加索引

mysql> alter table user add index ind_mo(mo);

mysql>SELECT uid FROM `user` WHERE mo=13772556391 LIMIT 0,1;

Empty set (0.05 sec)

执行计划

mysql> explain  SELECT uid FROM `user` WHERE mo=13772556391 LIMIT 0,1\G;

*************************** 1. row ***************************

               id: 1

      select_type: SIMPLE

            table: user

             type: index

    possible_keys: ind_mo

              key: ind_mo

             rows: 1

            Extra: Using where; Using index

隐式转换案例一

表结构

  CREATE TABLE `user` (

  ……

  mo char(11) NOT NULL DEFAULT '' ,

  KEY ind_mo (mo)

  ……

  ) ENGINE=InnoDB;

执行计划

mysql> explain extended select uid from`user` where mo=13772556391 limit 0,1;

mysql> show warnings;

Warning1：Cannot use  index 'ind_mo' due to type or collation conversion on field 'mo'

Note：select `user`.`uid` AS `uid` from `user` where (`user`.`mo` = 13772556391) limit 0,1

如何解决

mysql> explain   SELECT uid FROM `user` WHERE mo='13772556391' LIMIT 0,1\G;

*************************** 1. row ***************************

              id: 1

     select_type: SIMPLE

           table: user

            type: ref

   possible_keys: ind_mo

             key: ind_mo

            rows: 1

           Extra: Using where; Using index

上述案例中由于表结构定义mo字段后字符串数据类型，而应用传入的则是数字，进而导致了隐式转换，索引无法使用，所以有两种方案：
第一，将表结构mo修改为数字数据类型。
第二，修改应用将应用中传入的字符类型改为数据类型。

隐式转换案例二

表结构

CREATE TABLE `test_date` (

     `id` int(11) DEFAULT NULL,

     `gmt_create` varchar(100) DEFAULT NULL,

     KEY `ind_gmt_create` (`gmt_create`)

) ENGINE=InnoDB AUTO_INCREMENT=524272;

5.5版本执行计划

mysql> explain  select * from test_date where gmt_create BETWEEN DATE_ADD(NOW(), INTERVAL - 1 MINUTE) AND   DATE_ADD(NOW(), INTERVAL 15 MINUTE) ;

+----+-------------+-----------+-------+----------------+----------------+---------+------+------+-------------+

| id | select_type | table | type | possible_keys  | key | key_len | ref  | rows | Extra       |

+----+-------------+-----------+-------+----------------+----------------+---------+------+------+-------------+

|1|SIMPLE| test_date |range| ind_gmt_create|ind_gmt_create|303| NULL | 1 | Using where |

5.6版本执行计划

mysql> explain select * from test_date where gmt_create BETWEEN DATE_ADD(NOW(), INTERVAL - 1 MINUTE) AND   DATE_ADD(NOW(), INTERVAL 15 MINUTE) ;

+----+-------------+-----------+------+----------------+------+---------+------+---------+-------------+

| id | select_type | table | type | possible_keys  | key  | key_len | ref | rows | Extra|

+----+-------------+-----------+------+----------------+------+---------+------+---------+-------------+

| 1 | SIMPLE| test_date | ALL | ind_gmt_create | NULL | NULL | NULL | 2849555 | Using where |

+----+-------------+-----------+------+----------------+------+---------+------+---------+-------------+

|Warning|Cannot use range access on index 'ind_gmt_create' due to type on field 'gmt_create'

上述案例是用户在5.5版本升级到5.6版本后出现的隐式转换，导致数据库cpu压力100%，所以我们在定义时间字段的时候一定要采用时间类型的数据类型。

隐式转换案例三

表结构

  CREATE TABLE `t1` (

  `c1` varchar(100) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL,

  `c2` varchar(100) DEFAULT NULL,

  KEY `ind_c1` (`c1`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 

CREATE TABLE `t2` (

  `c1` varchar(100) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,

  `c2` varchar(100) DEFAULT NULL,

  KEY `ind_c2` (`c2`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8

执行计划

mysql> explain     select t1.* from  t2 left  join  t1 on t1.c1=t2.c1 where t2.c2='b';

+----+-------------+-------+------+---------------+--------+---------+-------+--------+-------------+

| id | select_type | table | type | possible_keys |key| key_len | ref   | rows   | Extra    |

+----+-------------+-------+------+---------------+--------+---------+-------+--------+-------------+

| 1 | SIMPLE | t2 | ref  | ind_c2 | ind_c2 | 303     | const |    258 | Using where |

|1  |SIMPLE |t1  |ALL   | NULL   | NULL   | NULL    | NULL  | 402250 |    |

修改COLLATE

mysql> alter table t1 modify column c1 varchar(100) COLLATE utf8_bin ;

Query OK, 401920 rows affected (2.79 sec)

Records: 401920  Duplicates: 0  Warnings: 0

执行计划

mysql> explain   select t1.* from  t2 left  join  t1 on t1.c1=t2.c1 where t2.c2='b';

+----+-------------+-------+------+---------------+--------+---------+------------+-------+-------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref | rows  | Extra       |

+----+-------------+-------+------+---------------+--------+---------+------------+-------+-------------+

|  1 | SIMPLE| t2| ref | ind_c2| ind_c2 | 303     | const      |   258 | Using where |

|  1 |SIMPLE| t1|ref| ind_c1  | ind_c1 | 303     | test.t2.c1 | 33527 |             |

+----+-------------+-------+------+---------------+--------+---------+------------+-------+-------------+

可以看到修改了字段的COLLATE后执行计划使用到了索引，所以一定要注意表字段的collate属性的定义保持一致。