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属性的定义保持一致。

两个索引的常见误区

  • 误区一：对查询条件的每个字段建立单列索引，例如查询条件为：A=？and B=？and C=？。 
    在表上创建了3个单列查询条件的索引ind_A(A)，ind_B(B)，ind_C(C)，应该根据条件的过滤性，创建适当的单列索引或者组合索引。
  • 误区二：对查询的所有字段建立组合索引，例如查询条件为select A,B,C,D,E,F from T where G=？。 
    在表上创建了ind_A_B_C_D_E_F_G(A,B,C,D,E,F,G)。

索引最佳实践

    • 在使用索引时，我们可以通过explain+extended查看SQL的执行计划，判断是否使用了索引以及发生了隐式转换。
    • 由于常见的隐式转换是由字段数据类型以及collation定义不当导致，因此我们在设计开发阶段，要避免数据库字段定义，避免出现隐式转换。
    • 由于MySQL不支持函数索引，在开发时要避免在查询条件加入函数，例如date(gmt_create)。
    • 所有上线的SQL都要经过严格的审核，创建合适的索引。
时间： 2024-10-12 07:21:35

SQL优化 · 经典案例 · 索引篇的相关文章

SQL优化基础 使用索引（一个小例子）

按照本文操作和体会,会对sql优化有个基本最简单的了解,其他深入还需要更多资料和实践的学习: 1. 建表: 复制代码 代码如下: create table site_user ( id int IDENTITY(1,1) PRIMARY KEY, [name] varchar(20), code varchar(20), date datetime ) 2. 插入8万条数据 复制代码 代码如下: declare @m int set @m=1 while @m<80000 begin INSER

Oracle优化经典文章------索引原理篇

Oracle提供了大量索引选项.知道在给定条件下使用哪个选项对于一个应用程序的性能来说非常重要.一个错误的选择可能会引发死锁,并导致数据库性能急剧下降或进程终止.而如果做出正确的选择,则可以合理使用资源,使那些已经运行了几个小时甚至几天的进程在几分钟得以完成,这样会使您立刻成为一位英雄.这篇文章就将简单的讨论每个索引选项.主要有以下内容:    [1] 基本的索引概念    查询DBA_INDEXES视图可得到表中所有索引的列表,注意只能通过USER_INDEXES的方法来检索模式(schema

MySQL SQL优化之字符串索引隐式转换

之前有用户很不解:SQL语句非常简单,就是select * from test_1 where user_id=1 这种类型,而且user_id上已经建立索引了,怎么还是查询很慢? test_1的表结构: CREATE TABLE `test_1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` varchar(30) NOT NULL, `name` varchar(30) DEFAULT NULL, PRIMARY KEY (`id`),

sql优化神器、索引

用法: explain  select * from ems_expense_feedback  where expenseId=333 rows列 表示 sql执行时检索次数,越小越好 根据上面的结果再适当加上索引 1.添加PRIMARY KEY(主键索引) mysql>ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) 2.添加UNIQUE(唯一索引) mysql>ALTER TABLE `table_name` ADD UNIQUE

优化系列 | 游戏数据表拆分优化经典案例

1. 目的通过对比测试,分析某数据表tabC拆分方案前后性能对比,确定拆分方案的可行性. 2. 方法对拆分方案前后两种类型进行对比测试.同时,每次测试中采用两种更新方式:1. 和原来类似,对数据表所有字段的更新分多次2. 对数据表所有字段的更新一次性完成 3. 环境本次测试采用线上实际数据导入.tabC表共有132万行记录,全表共100G.将所有字段重新组合,确保每个分表的实际行长度不高于8KB,拆分成3个子表,大小分别是:tabC_1.ibd 796MtabC_2.ibd 10.2GtabC_

浅谈SQL优化入门：3、利用索引

0.写在前面的话 关于索引的内容本来是想写的,大概收集了下资料,发现并没有想象中的简单,又不想总结了,纠结了一下,决定就大概写点浅显的,好吧,就是懒,先挖个浅坑,以后再挖深一点.最基本的使用很简单,直接就写在这里吧. 索引是众所周知的可以提高查询的速度,且针对的是具体的字段,使用方式为( 不具体指明则建立非聚集索引): CREATE INDEX <索引名> ON <表名(关系名)>; e.g. CREATE INDEX yearIndex ON movie(year); 而撤销索引

SQL优化之语句优化

昨天Qi号与大家分享了SQL优化中的索引优化,今天给大家聊一下,在开发过程中高质量的代码也是会带来优化的 网上关于SQL优化的教程很多,但是比较杂乱.Qi整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充. SQL语句优化,简单的说就是对SQL语句进行高效率的代码编写,其原理其实与SQL索引优化一致: 建立索引其实就是减少数据库在执行时所扫描的影响行数,尽可能的避免全局扫描 优化注意:对查询进行优化,要尽量避免全表扫描,首先应考虑在 where 及 order by 涉及

SQL Server数据库性能优化之索引篇【转】

http://www.blogjava.net/allen-zhe/archive/2010/07/23/326966.html 性能优化之索引篇 近期项目需要, 做了一段时间的SQL Server性能优化,遇到了一些问题,也积累了一些经验,现总结一下,与君共享.SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能. 操作系统的性能,甚至网卡.交换机等.这篇文章主要讲到如何改善索引,还将有另一篇讨论

SQL Server数据库性能优化之索引篇

SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能.操作系统的性能,甚至网卡.交换机等.这篇文章主要讲到如何改善索引 当根据索引码的值搜索数据时,索引提供了对数据的快速访问.事实上,没有索引,数据库也能根据SELECT语句成功地检索到结果,但随着表变得越来越大,使用“适当”的索引的效果就越来越明显.索引有助于提高检索性能,但过多或不当的索引也会导致系统低效.因为用户在表中每加进一个索引,数据库就要