一篇文章搞定 MySQL 索引优化

本文主要讨论MySQL索引的部分知识。将会从MySQL索引基础、索引优化实战和数据库索引背后的数据结构三部分相关内容，下面一一展开（本文图片可点开放大）。

1、MySQL索引基础

首先，咱们将从索引基础开始介绍一下什么是索引，分析索引的几种类型，并探讨一下如何建立索引以及索引设计的基本原则。

此部分用于测试索引建立的user表的结构以下：

1. 什么是索引？

“索引（在MySQL中也叫“键key”）是存储引擎快速找到记录的一种数据结构。”

——《高性能MySQL》

咱们须要知道索引实际上是一种数据结构，其功能是帮助咱们快速匹配查找到须要的数据行，是数据库性能优化最经常使用的工具之一。其做用至关于超市里的导购员、书本里的目录。

2. 索引类型

可使用SHOW INDEX FROM table_name;查看索引详情：

主键索引 PRIMARY KEY：它是一种特殊的惟一索引，不容许有空值。通常是在建表的时候同时建立主键索引。注意：一个表只能有一个主键。

惟一索引 UNIQUE：惟一索引列的值必须惟一，但容许有空值。若是是组合索引，则列值的组合必须惟一。能够经过ALTER TABLE table_name ADD UNIQUE (column);建立惟一索引：

能够经过ALTER TABLE table_name ADD UNIQUE (column1,column2);建立惟一组合索引：

普通索引 INDEX：这是最基本的索引，它没有任何限制。能够经过ALTER TABLE table_name ADD INDEX index_name (column);建立普通索引：

组合索引 INDEX：即一个索引包含多个列，多用于避免回表查询。能够经过ALTER TABLE table_name ADD INDEX index_name(column1,column2, column3);建立组合索引：

全文索引 FULLTEXT：也称全文检索，是目前搜索引擎使用的一种关键技术。能够经过ALTER TABLE table_name ADD FULLTEXT (column);建立全文索引：

索引一经建立不能修改，若是要修改索引，只能删除重建。可使用

DROP INDEX index_name ON table_name;删除索引。

三、索引设计的原则

1）适合索引的列是出如今where子句中的列，或者链接子句中指定的列；

2）基数较小的类，索引效果较差，没有必要在此列创建索引；

3）使用短索引，若是对长字符串列进行索引，应该指定一个前缀长度，这样可以节省大量索引空间；

4）不要过分索引。索引须要额外的磁盘空间，并下降写操做的性能。在修改表内容的时候，索引会进行更新甚至重构，索引列越多，这个时间就会越长。因此只保持须要的索引有利于查询便可。

2、MySQL索引优化实战

上面咱们介绍了索引的基本内容，这部分咱们介绍索引优化实战。在介绍索引优化实战以前，首先要介绍两个与索引相关的重要概念，这两个概念对于索引优化相当重要。

此部分用于测试的user表结构：

一、索引相关的重要概念

基数：单个列惟一键（distict_keys）的数量叫作基数。

SELECT COUNT(DISTINCT name),COUNT(DISTINCT gender) FROM user;

user表的总行数是5，gender列的基数是2，说明gender列里面有大量重复值，name列的基数等于总行数，说明name列没有重复值，至关于主键。

返回数据的比例：user表中共有5条数据：

SELECT * FROM user;

查询知足性别为0（男）的记录数：

那么返回记录的比例数是：

同理，查询name为'swj'的记录数：

返回记录的比例数是：

如今问题来了，假设name、gender列都有索引，那么SELECT * FROM user WHERE gender = 0; SELECT * FROM user WHERE name = 'swj';都能命中索引吗？

user表的索引详情：

SELECT * FROM user WHERE gender = 0;没有命中索引，注意filtered的值就是上面咱们计算的返回记录的比例数。

SELECT * FROM user WHERE name = 'swj';命中了索引index_name，由于走索引直接就能找到要查询的记录，因此filtered的值为100。

所以，返回表中30%内的数据会走索引，返回超过30%数据就使用全表扫描。固然这个结论太绝对了，也并非绝对的30%，只是一个大概的范围。

回表：当对一个列建立索引以后，索引会包含该列的键值及键值对应行所在的rowid。经过索引中记录的rowid访问表中的数据就叫回表。回表次数太多会严重影响SQL性能，若是回表次数太多，就不该该走索引扫描，应该直接走全表扫描。

EXPLAIN命令结果中的Using Index意味着不会回表，经过索引就能够得到主要的数据。Using Where则意味着须要回表取数据。

2. 索引优化实战

有些时候虽然数据库有索引，可是并不被优化器选择使用。咱们能够经过SHOW STATUS LIKE 'Handler_read%';查看索引的使用状况：

Handler_read_key：若是索引正在工做，Handler_read_key的值将很高。

Handler_read_rnd_next：数据文件中读取下一行的请求数，若是正在进行大量的表扫描，值将较高，则说明索引利用不理想。

索引优化规则：

1）若是MySQL估计使用索引比全表扫描还慢，则不会使用索引。

返回数据的比例是重要的指标，比例越低越容易命中索引。记住这个范围值——30%，后面所讲的内容都是创建在返回数据的比例在30%之内的基础上。

2）前导模糊查询不能命中索引。

name列建立普通索引：

前导模糊查询不能命中索引：

EXPLAIN SELECT * FROM user WHERE name LIKE '%s%';

非前导模糊查询则可使用索引，可优化为使用非前导模糊查询：

EXPLAIN SELECT * FROM user WHERE name LIKE 's%';

3）数据类型出现隐式转换的时候不会命中索引，特别是当列类型是字符串，必定要将字符常量值用引号引发来。

EXPLAIN SELECT * FROM user WHERE name=1;

EXPLAIN SELECT * FROM user WHERE name='1';

4）复合索引的状况下，查询条件不包含索引列最左边部分（不知足最左原则），不会命中符合索引。

name,age,status列建立复合索引：

ALTER TABLE user ADD INDEX index_name (name,age,status);

user表索引详情：

SHOW INDEX FROM user;

根据最左原则，能够命中复合索引index_name：

EXPLAIN SELECT * FROM user WHERE name='swj' AND status=1;

注意，最左原则并非说是查询条件的顺序：

EXPLAIN SELECT * FROM user WHERE status=1 AND name='swj';

而是查询条件中是否包含索引最左列字段：

EXPLAIN SELECT * FROM user WHERE status=2 ;

5）union、in、or都可以命中索引，建议使用in。

union:

EXPLAIN SELECT*FROM user WHERE status=1

UNION ALL

SELECT*FROM user WHERE status = 2;

in:

EXPLAIN SELECT * FROM user WHERE status IN (1,2);

or:

EXPLAIN SELECT*FROM user WHERE status=1OR status=2;

查询的CPU消耗：or>in>union。

6）用or分割开的条件，若是or前的条件中列有索引，然后面的列中没有索引，那么涉及到的索引都不会被用到。

EXPLAIN SELECT * FROM payment WHERE customer_id = 203 OR amount = 3.96;

由于or后面的条件列中没有索引，那么后面的查询确定要走全表扫描，在存在全表扫描的状况下，就没有必要多一次索引扫描增长IO访问。

7）负向条件查询不能使用索引，能够优化为in查询。

负向条件有：!=、<>、not in、not exists、not like等。

status列建立索引：

ALTER TABLE user ADD INDEX index_status (status);

user表索引详情：

SHOW INDEX FROM user;

负向条件不能命中缓存：

EXPLAIN SELECT * FROM user WHERE status !=1 AND status != 2;

能够优化为in查询，可是前提是区分度要高，返回数据的比例在30%之内：

EXPLAIN SELECT * FROM user WHERE status IN (0,3,4);

8）范围条件查询能够命中索引。范围条件有：<、<=、>、>=、between等。

status,age列分别建立索引：

ALTER TABLE user ADD INDEX index_status (status);

ALTER TABLE user ADD INDEX index_age (age);

user表索引详情：

SHOW INDEX FROM user;

范围条件查询能够命中索引：

EXPLAIN SELECT * FROM user WHERE status>5;

范围列能够用到索引（联合索引必须是最左前缀），可是范围列后面的列没法用到索引，索引最多用于一个范围列，若是查询条件中有两个范围列则没法全用到索引：

EXPLAIN SELECT * FROM user WHERE status>5 AND age<24;

若是是范围查询和等值查询同时存在，优先匹配等值查询列的索引：

EXPLAIN SELECT * FROM user WHERE status>5 AND age=24;

8）数据库执行计算不会命中索引。

EXPLAIN SELECT * FROM user WHERE age>24;

EXPLAIN SELECT * FROM user WHERE age+1>24;

计算逻辑应该尽可能放到业务层处理，节省数据库的CPU的同时最大限度的命中索引。

9）利用覆盖索引进行查询，避免回表。

被查询的列，数据能从索引中取得，而不用经过行定位符row-locator再到row上获取，即“被查询列要被所建的索引覆盖”，这可以加速查询速度。

user表的索引详情：

由于status字段是索引列，因此直接从索引中就能够获取值，没必要回表查询：

Using Index表明从索引中查询：

EXPLAIN SELECT status FROM user where status=1;

当查询其余列时，就须要回表查询，这也是为何要避免SELECT*的缘由之一：

EXPLAIN SELECT * FROM user where status=1;

10）创建索引的列，不容许为null。

单列索引不存null值，复合索引不存全为null的值，若是列容许为null，可能会获得“不符合预期”的结果集，因此，请使用not null约束以及默认值。

remark列创建索引：

ALTER TABLE user ADD INDEX index_remark (remark);

IS NULL能够命中索引：

EXPLAIN SELECT * FROM user WHERE remark IS NULL;

IS NOT NULL不能命中索引：

EXPLAIN SELECT * FROM user WHERE remark IS NOT NULL;

虽然IS NULL能够命中索引，可是NULL自己就不是一种好的数据库设计，应该使用NOT NULL约束以及默认值。

a. 更新十分频繁的字段上不宜创建索引：由于更新操做会变动B+树，重建索引。这个过程是十分消耗数据库性能的。

b. 区分度不大的字段上不宜创建索引：相似于性别这种区分度不大的字段，创建索引的意义不大。由于不能有效过滤数据，性能和全表扫描至关。另外返回数据的比例在30%之外的状况下，优化器不会选择使用索引。

c. 业务上具备惟一特性的字段，即便是多个字段的组合，也必须建成惟一索引。虽然惟一索引会影响insert速度，可是对于查询的速度提高是很是明显的。另外，即便在应用层作了很是完善的校验控制，只要没有惟一索引，在并发的状况下，依然有脏数据产生。

d. 多表关联时，要保证关联字段上必定有索引。

e. 建立索引时避免如下错误观念：索引越多越好，认为一个查询就须要建一个索引；宁缺勿滥，认为索引会消耗空间、严重拖慢更新和新增速度；抵制惟一索引，认为业务的惟一性一概须要在应用层经过“先查后插”方式解决；过早优化，在不了解系统的状况下就开始优化。

3. 小结

对于本身编写的SQL查询语句，要尽可能使用EXPLAIN命令分析一下，作一个对SQL性能有追求的程序员。衡量一个程序员是否靠谱，SQL能力是一个重要的指标。做为后端程序员，深觉得然。

---

扫描下方二维码，及时获取更多互联网求职面经、java、python、爬虫、大数据等技术，和海量资料分享：公众号后台回复“csdn”便可免费领取【csdn】和【百度文库】下载服务；公众号后台回复“资料”:便可领取5T精品学习资料、java面试考点和java面经总结，以及几十个java、大数据项目，资料很全，你想找的几乎都有

推荐阅读

☞真实靠谱：百度的职级、薪资、及晋升潜规则