一、MYSQL的索引
索引（Index）:
索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。是帮助Mysql高效获取数据的一种数据结构。用于提高查找效率，可以比作字典。可以简单理解为排好序的快速查找的数据结构。（注：一般数据库默认都会为主键生成索引）。索引的作用：
在数据之外，数据库还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用数据。这样就可以在这些数据结构上实现高级查找算法。这些数据结构就是索引。
索引本身也很大，不可能全部存储在内存中，所以索引往往以索引文件的形式存储在磁盘上。
我们平时所说的索引，如果没有特别指明，一般都是B树索引。（聚集索引、复合索引、前缀索引、唯一索引默认都是B+树索引），除了B树索引还有哈希索引。
B、通过索引列对数据进行排序，降低了数据排序成本，降低了CPU的消耗。
B、对表进行INSERT、UPDATE、DELETE操作时，MYSQL不仅会更新数据，还要保存一下索引文件每次更新添加了索引列字段的相应信息。
在实际的生产环境中我们需要逐步分析，优化建立最优的索引，并要优化我们的查询条件。
非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，myisam通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，这也就是为什么索引不在key buffer命中时，速度慢的原因
聚簇索引与非聚簇索引区别:
聚簇索引的叶节点就是数据节点，而非聚簇索引的叶节点仍然是索引节点，并保留一个链接指向对应数据块。
聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。
相比之下，聚簇索引适合排序，非聚簇索引不适合用在排序的场合。因为聚簇索引叶节点本身就是索引和数据按相同顺序放置在一起，索引序即是数据序，数据序即是索引序，所以很快。非聚簇索引叶节点是保留了一个指向数据的指针，索引本身当然是排序的，但是数据并未排序，数据查询的时候需要消耗额外更多的I/O，所以较慢。
当你需要取出一定范围内的数据时，用聚簇索引也比用非聚簇索引好。
分七步完成。
一个误区：把主键自动设为聚簇索引
聚簇索引默认是主键，如果表中没有定义主键，InnoDB 会选择一个唯一的非空索引代替。如果没有这样的索引，InnoDB 会隐式定义一个主键来作为聚簇索引。InnoDB 只聚集在同一个页面中的记录。包含相邻健值的页面可能相距甚远。如果你已经设置了主键为聚簇索引，必须先删除主键，然后添加我们想要的聚簇索引，最后恢复设置主键即可。
此时其他索引只能被定义为非聚簇索引,这个是最大的误区。有的主键还是无意义的自动增量字段，那样的话Clustered index对效率的帮助，完全被浪费了。
刚才说到了，聚簇索引性能最好而且具有唯一性，所以非常珍贵，必须慎重设置。一般要根据这个表最常用的SQL查询方式来进行选择，某个字段作为聚簇索引，或组合聚簇索引，这个要看实际情况。
记住我们的最终目的就是在相同结果集情况下，尽可能减少逻辑IO。
eg:
–创建表的适合添加全文索引 CREATE TABLE article ( id int(11) NOT NULL AUTO_INCREMENT , title char(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL , content text CHARACTER SET utf8 COLLATE utf8_general_ci NULL , time int(10) NULL DEFAULT NULL , PRIMARY KEY (`id`), FULLTEXT (content) ); –修改表结构添加全文索引 ALTER TABLE article ADD FULLTEXT index_content(content) –直接创建索引 CREATE FULLTEXT INDEX index_content ON article(content)
主键索引和唯一索引的区别:
主键是一种约束，唯一索引是一种索引，两者在本质上是不同的。
主键创建后一定包含一个唯一性索引，唯一性索引并不一定就是主键。
唯一性索引列允许空值，而主键列不允许为空值。
主键列在创建时，已经默认为空值 + 唯一索引了。
主键可以被其他表引用为外键，而唯一索引不能。
一个表最多只能创建一个主键，但可以创建多个唯一索引。
主键更适合那些不容易更改的唯一标识，如自动递增列、身份证号等。
在 RBO 模式下，主键的执行计划优先级要高于唯一索引。 两者可以提高查询的速度。
语法：
创建 1、CREATE [UNIQUE] INDEX indexName ON myTable (columnName(length));
2、ALTER myTable Add [UNIQUE] INDEX [indexName] ON (columnName(length));
删除：DROP INDEX [indexName] ON myTable;
查看： SHOW INDEX FROM table_nameG;
索引的优化
上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。下面是一些总结以及收藏的MySQL索引的注意事项和优化方法。
1. 何时使用聚集索引或非聚集索引？
| 动作描述 | 使用聚集索引 | 使用非聚集索引 |
| 列经常被分组排序 | 使用 | 使用 |
| 返回某范围内的数据 | 使用 | 不使用 |
| 一个或极少不同值 | 不使用 | 不使用 |
| 小数目的不同值 | 使用 | 不使用 |
| 大数目的不同值 | 不使用 | 使用 |
| 频繁更新的列 | 不使用 | 使用 |
| 外键列 | 使用 | 使用 |
| 主键列 | 使用 | 使用 |
| 频繁修改索引列 | 不使用 | 使用 |
事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。其实这个具体用法我还不是很理解，只能等待后期的项目开发中慢慢学学了。
2. 索引不会包含有NULL值的列
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。
3. 使用短索引
对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
4. 索引列排序
MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
5. like语句操作
一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
6. 不要在列上进行运算
例如：select * from users where YEAR(adddate)<2007，将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成：select * from users where adddate<’2007-01-01′。关于这一点可以围观：一个单引号引发的MYSQL性能损失。
最后总结一下，MySQL只对一下操作符才使用索引：<,<=,=,>,>=,between,in,以及某些时候的like(不以通配符%或_开头的情形)。而理论上每张表里面最多可创建16个索引，不过除非是数据量真的很多，否则过多的使用索引也不是那么好玩的，比如我刚才针对text类型的字段创建索引的时候，系统差点就卡死了。
二、EXPLAIN 的作用
EXPLAIN :模拟Mysql优化器是如何执行SQL查询语句的，从而知道Mysql是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。
mysql> explain select * from tb_user; +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+---------------+------+---------+------+------+-------+ | 1 | SIMPLE | tb_user | ALL | NULL | NULL | NULL | NULL | 1 | NULL | +----+-------------+---------+------+---------------+------+---------+------+------+-------+
(一)id列：
(1)、id 相同执行顺序由上到下
mysql> explain
-> SELECT*FROM tb_order tb1
-> LEFT JOIN tb_product tb2 ON tb1.tb_product_id = tb2.id
-> LEFT JOIN tb_user tb3 ON tb1.tb_user_id = tb3.id;
+----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+
| 1 | SIMPLE | tb1 | ALL | NULL | NULL | NULL | NULL | 1 | NULL |
| 1 | SIMPLE | tb2 | eq_ref | PRIMARY | PRIMARY | 4 | product.tb1.tb_product_id | 1 | NULL |
| 1 | SIMPLE | tb3 | eq_ref | PRIMARY | PRIMARY | 4 | product.tb1.tb_user_id | 1 | NULL |
+----+-------------+-------+--------+---------------+---------+---------+---------------------------+------+-------+
(2)、如果是子查询，id序号会自增，id值越大优先级就越高，越先被执行。
mysql> EXPLAIN
-> select * from tb_product tb1 where tb1.id = (select tb_product_id from tb_order tb2 where id = tb2.id =1);
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
| 1 | PRIMARY | tb1 | const | PRIMARY | PRIMARY | 4 | const | 1 | NULL |
| 2 | SUBQUERY | tb2 | ALL | NULL | NULL | NULL | NULL | 1 | Using where |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------------+
(3)、id 相同与不同，同时存在
mysql> EXPLAIN
-> select * from(select * from tb_order tb1 where tb1.id =1) s1,tb_user tb2 where s1.tb_user_id = tb2.id;
+----+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
| 1 | PRIMARY | <derived2> | system | NULL | NULL | NULL | NULL | 1 | NULL |
| 1 | PRIMARY | tb2 | const | PRIMARY | PRIMARY | 4 | const | 1 | NULL |
| 2 | DERIVED | tb1 | const | PRIMARY | PRIMARY | 4 | const | 1 | NULL |
+----+-------------+------------+--------+---------------+---------+---------+-------+------+-------+
derived2：衍生表 2表示衍生的是id=2的表 tb1
（二）select_type列：数据读取操作的操作类型
1、SIMPLE:简单的select 查询，SQL中不包含子查询或者UNION。
2、PRIMARY:查询中包含复杂的子查询部分，最外层查询被标记为PRIMARY
3、SUBQUERY:在select 或者WHERE 列表中包含了子查询
4、DERIVED:在FROM列表中包含的子查询会被标记为DERIVED(衍生表)，MYSQL会递归执行这些子查询，把结果集放到临时表中。
5、UNION:如果第二个SELECT 出现在UNION之后，则被标记位UNION；如果UNION包含在FROM子句的子查询中，则外层SELECT 将被标记为DERIVED
6、UNION RESULT:从UNION表获取结果的select
（三）table列：该行数据是关于哪张表
（四）type列：访问类型 由好到差system > const > eq_ref > ref > range > index > ALL
1、system:表只有一条记录(等于系统表),这是const类型的特例，平时业务中不会出现。
2、const:通过索引一次查到数据，该类型主要用于比较primary key 或者unique 索引，因为只匹配一行数据，所以很快;如果将主键置于WHERE语句后面，Mysql就能将该查询转换为一个常量。
3、eq_ref:唯一索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或者唯一索引扫描。
4、ref:非唯一索引扫描，返回匹配某个单独值得所有行，本质上是一种索引访问，它返回所有匹配某个单独值的行，就是说它可能会找到多条符合条件的数据，所以他是查找与扫描的混合体。
详解：这种类型表示mysql会根据特定的算法快速查找到某个符合条件的索引，而不是会对索引中每一个数据都进行一 一的扫描判断，也就是所谓你平常理解的使用索引查询会更快的取出数据。而要想实现这种查找，索引却是有要求的，要实现这种能快速查找的算法，索引就要满足特定的数据结构。简单说，也就是索引字段的数据必须是有序的，才能实现这种类型的查找，才能利用到索引。
5、range：只检索给定范围的行，使用一个索引来选着行。key列显示使用了哪个索引。一般在你的WHERE 语句中出现between 、< 、> 、in 等查询，这种给定范围扫描比全表扫描要好。因为他只需要开始于索引的某一点，而结束于另一点，不用扫描全部索引。
6、index：FUll Index Scan 扫描遍历索引树(index：这种类型表示是mysql会对整个该索引进行扫描。要想用到这种类型的索引，对这个索引并无特别要求，只要是索引，或者某个复合索引的一部分，mysql都可能会采用index类型的方式扫描。但是呢，缺点是效率不高，mysql会从索引中的第一个数据一个个的查找到最后一个数据，直到找到符合判断条件的某个索引）。
7、ALL 全表扫描 从磁盘中获取数据 百万级别的数据ALL类型的数据尽量优化。
（五）possible_keys列:显示可能应用在这张表的索引，一个或者多个。查询涉及到的字段若存在索引，则该索引将被列出，但不一定被查询实际使用。
（六）keys列:实际使用到的索引。如果为NULL，则没有使用索引。查询中如果使用了覆盖索引，则该索引仅出现在key列表中。覆盖索引：select 后的 字段与我们建立索引的字段个数一致。
（七）ken_len列:表示索引中使用的字节数，可通过该列计算查询中使用的索引长度。在不损失精确性的情况下，长度越短越好。key_len 显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出来的。
（八）ref列:显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值。
（九）rows列(每张表有多少行被优化器查询):根据表统计信息及索引选用的情况，大致估算找到所需记录需要读取的行数。
（十）Extra列：扩展属性，但是很重要的信息。
1、 Using filesort(文件排序)：mysql无法按照表内既定的索引顺序进行读取。 mysql> explain select order_number from tb_order order by order_money; +----+-------------+----------+------+---------------+------+---------+------+------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+------+----------------+ | 1 | SIMPLE | tb_order | ALL | NULL | NULL | NULL | NULL | 1 | Using filesort | +----+-------------+----------+------+---------------+------+---------+------+------+----------------+ 1 row in set (0.00 sec) 说明：order_number是表内的一个唯一索引列，但是order by 没有使用该索引列排序，所以mysql使用不得不另起一列进行排序。 2、Using temporary:Mysql使用了临时表保存中间结果，常见于排序order by 和分组查询 group by。 mysql> explain select order_number from tb_order group by order_money; +----+-------------+----------+------+---------------+------+---------+------+------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+------+---------------------------------+ | 1 | SIMPLE | tb_order | ALL | NULL | NULL | NULL | NULL | 1 | Using temporary; Using filesort | +----+-------------+----------+------+---------------+------+---------+------+------+---------------------------------+ 1 row in set (0.00 sec) 3、Using index 表示相应的select 操作使用了覆盖索引，避免访问了表的数据行，效率不错。 如果同时出现Using where ，表明索引被用来执行索引键值的查找。 如果没有同时出现using where 表明索引用来读取数据而非执行查找动作。 mysql> explain select order_number from tb_order group by order_number; +----+-------------+----------+-------+--------------------+--------------------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+-------+--------------------+--------------------+---------+------+------+-------------+ | 1 | SIMPLE | tb_order | index | index_order_number | index_order_number | 99 | NULL | 1 | Using index | +----+-------------+----------+-------+--------------------+--------------------+---------+------+------+-------------+ 1 row in set (0.00 sec) 4、Using where 查找 5、Using join buffer ：表示当前sql使用了连接缓存。 6、impossible where ：where 字句 总是false ，mysql 无法获取数据行。 7、select tables optimized away： 8、distinct：
文献参考:https://www.cnblogs.com/jalja/p/7670712.html
https://www.cnblogs.com/s-b-b/p/8334593.html