万字干货总结：MySQL优化原理学习，这一篇就够了！

懂得索引选择性的概念后，就不难肯定哪个字段的选择性较高了，查一下就知道了，比如：

SELECT * FROM payment where staff_id = 2 and customer_id = 584

是应当创建 (staff_id,customer_id) 的索引照样应当倒置一下次序？履行下面的萌芽，哪个字段的选择性更接近 1 就把哪个字段索引前面就好。

多半情况下应用这个原则没有任何问题，但仍然留意你的数据中是否存在一些间谍作况。举个简单的例子，比如要萌芽某个用户组下有过交易的用户信息：

MySQL 为这个萌芽选择了索引 (user_group_id,trade_amount)，如不雅不推敲间谍作况，这看起来没有任何问题，但实际情况是这张表的大年夜多半数据都是大年夜老体系中迁徙过来的，因为新老体系的数据不兼容，所以就给老体系迁徙过来的数据付与了一个默认的用户组。这种情况下，经由过程索引扫描的行数跟全表扫描根本没什么差别，索引也就起不到任何感化。

实际开辟中，我们会经常应用多个范围前提，比如想萌芽某个时光段内登录过的用户：

select user.* from user where login_time > '2017-04-01' and age between 18 and 30;

这个萌芽有一个问题：它有两个范围前提，login_time 列和 age 列，MySQL 可以应用 login_time 列的索引或者 age 列的索引，但无法同时应用它们。

5. 覆盖索引

如不雅一个索引包含或者说覆盖所有须要萌芽的字段的值，那么就没有须要再回表萌芽，这就称为覆盖索引。覆盖索引是异常有效的对象，可以极大年夜的进步机能，因为萌芽只须要扫描索引会带来很多好处：

索引条目远小于数据行大年夜小，如不雅只攫取索引，极大年夜削减数据拜访量
索引是有按照列值次序存储的，对于 I/O 密集型典范围萌芽要比随机大年夜磁盘攫取每一行数据的 IO 要少的多

6. 应用索引扫描来排序

MySQL 有两种方法可以临盆有序的结不雅集，其一是对结不雅集进行排序的操作，其二是按照索引次序扫描得出的结不雅天然是有序的。如不雅 explain 的结不雅中 type 列的值为 index 表示应用了索引扫描来做排序。

扫描索引本身很快，因为只须要大年夜一条索引记录移动到相邻的下一笔记录。但如不雅索引本身不克不及覆盖所有须要萌芽的列，那么就不得不每扫描一条索引记录就回表萌芽一次对应的行。这个攫取操作根本上是随机 I/O，是以按照索引次序攫取数据的速度平日要比次序地全表扫描要慢。

在设计索引时，如不雅一个索引既可以或许知足排序，又知足萌芽，是最好的。

只有当索引的列次序和 ORDER BY 子句的次序完全一致，并且所有列的排序偏向也一样时，才能够应用索引来对结不雅做排序。如不雅萌芽须要接洽关系多张表，则只有 ORDER BY 子句引用的字段全部为第一张表时，才能应用索引做排序。ORDER BY 子句和萌芽的限制是一样的，都要知足最左前缀的请求（有一种情况例外，就是最左的列被指定为常数，下面是一个简单的示例），其它情况下都须要履行排序操作，而无法应用索引排序。

// 最左列为常数，索引：(date,staff_id,customer_id) 
 
select  staff_id,customer_id from demo where date = '2015-06-01' order by staff_id,customer_id

本文让你从新懂得并核阅那些风行的优化建议，并在实际营业场景下合理的应用。

7. 冗余和反复索引

冗余索引是指在雷同的列上按照雷同的次序创建的雷同类型的索引，应当尽量避免这种索引，发明后急速删除。比如有一个索引 (A,B)，再创建索引 (A) 就是冗余索引。冗余索引经常产生在为表添加新索引时，比如有人新建了索引 (A,B)，但这个索引不是扩大已有的索引 (A)。

大年夜多半情况下都应当尽量扩大已有的索引而不是创建新索引。但有极少情况下出现机能方面的┞峰酌须要冗余索引，比如扩大已有索引而导致其变得过大年夜，大年夜而影响到其他应用该索引的萌芽。

推广开来说，经验轨则和推论在多半情况下是有效的，可以指导我们开辟和设计，但实际情况往往会更复杂，实际营业场景下的某些间谍作况可能会摧毁你的┞符个设计。

8. 删除经久未应用的索引

在大年夜数据场景下，表与表之间经由过程一个冗余字段来接洽关系，要比直接应用 JOIN 有更好的机能。如不雅确切须要应用接洽关系萌芽的情况下，须要特别留意的是：

确保>
1. SELECT A.xx,B.yy
3. FROM A INNER JOIN B USING(c)