根据索引求行号 利用索引进行排序

通过索引进行优化

索引的优点
1、索引的优点：
(1)减少服务器扫描的数据量
(2)避免排序和临时表
(3)将随机 IO 变成顺序 IO
索引的用处
1、快速查找匹配WHERE子句的行
2、从consideration中消除行,如果可以在多个索引之间进行选择，mysql通常会使用找到最少行的索引
3、如果表具有多列索引，则优化器可以使用索引的任何最左前缀来查找行
4、当有表连接的时候，从其他表检索行数据
5、查找特定索引列的min或max值
6、如果排序或分组时在可用索引的最左前缀上完成的，则对表进行排序和分组
7、在某些情况下，可以优化查询以检索值而无需查询数据行
索引的分类
1、主键索引：当创建表的时候如果包含主键，那么数据库会默认给主键列添
加索引。一般情况下表中都是具有主键索引的；
2、唯一索引：给表中的唯一列添加的索引；
3、普通索引：又叫做二级索引或者辅助索引，表示的是除了主键、唯一键添
加的索引；
4、全文索引：一般是在 varchar、 char 或者说 text 这样的类型里面才会建全
文索引，全文索引类似于全文检索，例如，有一个文章表，里面有一个列是
content，存储的是文章的详细内容，如果需要检索包含 java 关键字的数据，此时
使用 like 效率一定很低，因此可以使用全文索引，有点像开源框架 es，但是在企
业级应用中一般用的很少；
5、组合索引：一般在创建索引的时候都会选择单列，在某些情况下需要给多
个列添加一个索引，此时就组成了组合索引。

回表
回表就是先通过数据库索引扫描出数据所在的行，再通过行主键 id 取出索引中未提供的数据，即基于非主键索引的查询需要多扫描一棵索引树。单说这个概念可能有点难以理解，我们举例来说明：假如有一个表中存在，id,name,age,gender四个列，id 是主键，name 是普通索引列，此时如果执行下面 sql 语句的话，应该如何检索数据呢？
Select * from table where name = ‘zhangsan’;
通过表分析我们知道，当前表中共有两个索引，分别是主键索引和普通索引，因为查询条件中包含 name 索引列的值，所以在检索的时候，会先查找 name 索引的 B+树，从叶子节点中获取到 id 的值，然后再根据 id 的值去主键 B+树中检索全部的数据，这个过程就称为回表，在整个检索过程中，需要遍历两个 B+树，然后返回最终的结果。大家也发现了，回表是比较浪费时间的，因为要进行两颗 B+树的检索，io 的次数会变多，因此在进行数据查找的时候尽量减少回表。

覆盖索引
索引覆盖是跟回表相反的概念，在索引的叶子节点中如果能获取到查询的所有列数据，无需回表的过程称之为索引覆盖。还是上面说的表结构，如果执行如下
sql 语句：
Select id，name from table where name=’zhangsan’;
此时通过分析我们知道，在 name 的索引树的叶子节点中，存在 id，name 两个列的值，所以通过 name 的检索，可以直接获取到需要查询的所有列，而不需要去主键的 B+树中查询，此过程称为覆盖索引。这个过程在检索的时候，io 次数是少的，效率比较高，因此推荐在 sql 优化的时候，尽量多的使用覆盖索引。

最左匹配
在一个表中，如果有组合索引，那么组合索引在进行查询的时候，遵循最左匹配的原则，表示必须要先匹配到第一个列之后才能匹配第二个列，无法直接匹配第二个列的值。举例如下：
一个表中包含 id,name,age,gender 四个列，id 是主键，name,age 是组合索引，那么在进行查询的时候会包含下面四条 sql 语句：
Select * from table where name = ‘zhangsan’ and age =10;
Select * from table where name = ‘zhangsan’;
Select * from table where age = 10;
Select * from table where age = 10 and name = ‘zhangsan’;

在上述四条 sql 语句中，只有第三条 sql 语句不会用到索引，原因也非常简单，没有匹配到 name 就直接匹配 age 了，所以此时是无法使用组合索引的。当然会有同学觉得第四条 sql 语句也不会用到索引，因为先匹配 age 再匹配name，此时要注意一件事，第四条 sql 语句的两个条件调整顺序之后对最终的结果是没有任何影响的，所以 mysql 中的优化器会对这个 sql 语句的条件进行优化，调整顺序，调整成跟第一条一样的效果，所以也是可以使用最左匹配原则的。

索引下推

索引下推表示的是数据筛选的过程下移到存储引擎层来完成，而不是在 server层完成。在刚开始的时候我们就解释了 mysql 的架构，包含了三个层次，分别是客户端，server 端，存储引擎。如果要执行如下的 sql 语句，那么执行过程是什么样子的呢？

Select * from where name = ‘zhangsan’ and age = 10;

在没有索引下推之前，会先根据 name 的值从存储引擎中将所有符合条件的结果加载到 server 端，然后在 server 端对 age 字段进行条件筛选。而使用索引下推之后，会根据 name 和 age 的结果直接从存储引擎中返回所有符合条件的结果，无需在 server 端做任何的数据筛选工作。对比两种方式，大家发现，不使用索引下推的时候，server 端跟存储引擎之间交互的数据 io 量一定大很多，所以使用索引下推是能够提升整体查询的效率的，这个特性在 5.7 版本之后是默认支持的，无需做任何设置，大家理解其中的意思即可。

索引匹配方式

建立测试表

create table staffs(

    id int primary key auto_increment,

    name varchar(24) not null default '' comment '姓名',

    age int not null default 0 comment '年龄',

    pos varchar(20) not null default '' comment '职位',

    add_time timestamp not null default current_timestamp comment '入职时间'

  ) charset utf8 comment '员工记录表';

alter table staffs add index idx_nap(name, age, pos);

全值匹配

全值匹配指的是和索引中的所有列进行匹配

explain select * from staffs where name = ‘July’ and age = ‘23’ and pos = ‘dev’;

ref显示索引的哪一列被使用了，显示三个常量。匹配最左前缀

只匹配前面的几列

explain select * from staffs where name = ‘July’ and age = ‘23’;

explain select * from staffs where name = ‘July’;

匹配列前缀

可以匹配某一列的值的开头部分

explain select * from staffs where name like ‘J%’;

explain select * from staffs where name like ‘%y’;

匹配范围值

可以查找某一个范围的数据

explain select * from staffs where name > ‘Mary’;

精确匹配某一列并范围匹配另外一列

可以查询第一列的全部和第二列的部分

explain select * from staffs where name = ‘July’ and age > 25;

只访问索引的查询

查询的时候只需要访问索引，不需要访问数据行，本质上就是覆盖索引

explain select name,age,pos from staffs where name = ‘July’ and age = 25 and pos = ‘dev’;

这个表示当前的查询时覆盖索引的，直接从索引中读取数据，而不用访问数据表。

哈希索引

在 InnoDB 和 MyISAM 的存储引擎中使用 B+树来存储索引，在 mysql 的memory 存储引擎中显式支持哈希索引。哈希索引是基于哈希表的实现，只有精确匹配所有的所有列的查询才有效，哈希索引自身只需存储对应的 hash 值，所以索引的结构十分紧凑，这让哈希索引查找的速度非常快。但是大家也需要注意，在使用哈希索引的时候有一堆的限制：
1、哈希索引只包含哈希值和行指针，而不存储字段值，索引不能使用索引中的值来避免读取行。每次查询必须要先匹配到哈希值，然后再读取行指针，再根据行指针去读取我们实际数据。IO次数多
2、哈希索引数据并不是按照索引值顺序存储的，所以无法进行排序。
3、哈希索引不支持部分列匹配查找，因为部分列的话，取到的哈希值可能跟之前存储的哈希值是不一样的，那么获取的数据就存在误差了。
4、哈希索引支持等值比较查询，但不支持任何范围查询，因为在进行范围查询的时候需要挨个值就行对比，此时的查询效率是比较低的。
5、访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候，存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行。
6、哈希冲突比较多的话，维护的代价也会很高。哈希索引有什么用途呢，举个例子说明下：当需要存储大量的 URL，并且根据 URL 进行搜索查找，如果使用 B+树，存储的内容就会很大
select id from url where url=“” 我们知道 URL 长度是不固定的，有可能很短有可能很长，但一般情况下是非常长的，如果把整个的 URL 都存储到 B+树中，那么会额外占用很多存储空间，这样会导致非叶子节点中，大量的存储空间被 url 所占用，那么想要存储更多的数据的话，就会导致整个 B+树比较深，从而导致查询变慢，那么怎么处理呢？可以将 url 使用 CRC32 做哈希，在查询的时候使用以下方式： select id fom url where url=“” and url_crc=CRC32(“”) ，此时查询性能较高，原因是使用 CRC32转换之后会变成一个整形类型的值，占用更小的存储空间，那么树的深度不会加深，从而加快数据访问效率。上面就是关于哈希索引的基本知识，面试的时候哈希索引问的很少，所以大家掌握核心的点就可以了。

组合索引

一般情况下，我们在创建索引的时候，会使用单列，但是在很多情况下会选择多列值作为索引，那么此时就是我们说的组合索引了，也有人称之为复合索引，无论叫做什么名字，大家知道表达的意思即可。在使用组合索引的时候，大家需要注意最左匹配原则，当创建组合索引之后，进行列值匹配的时候，需要从左向右匹配，这点切记。当创建了一张表，将表中的 a,b,c 三列作为组合索引的时候，要注意不同查询的索引匹配情况，如下图：

案例，建立组合索引a,b,c

where a=3 and b>10 and c=7 因为b>10 是范围比较，所以c索引用不到，范围比较后的索引失效。

聚簇索引与非聚簇索引

聚簇索引并不是单独的索引类型，而是一种数据存储方式，指的是数据跟对应的索引列紧凑的存储在一起。
非聚簇索引指的是数据跟索引分开存储。
假设有个 innodb 存储引擎表，表中有 id,name,age,gender 四个列，id 是主键，name，age 是普通索引，id 跟数据是绑定在一起的，而 name 和 age 对应的索引树的叶子节点存储的是主键的值，所以 id是聚簇索引，name，age 是非聚簇索引。
而对于 myisam 而言，数据跟索引本来就是分开存储的，所以，myisam 中支持的是非聚簇索引。
基于上面的分析，我们可以得到一个结论，innodb 中既支持聚簇索引，也支持非聚簇索引，而 myisam 中只支持非聚簇索引。
如果已经分清楚了聚簇索引和非聚簇索引的区别，那么来看一下聚簇索引的优
缺点，
聚簇索引的优点：
1、可以把相关数据保存在一起；
2、数据访问更快，因为数据跟索引保存在同一颗树中；
3、使用覆盖索引扫描的查询可以直接使用叶子节点中的主键值
聚簇索引的缺点：
1、聚簇数据最大限度地提高了 IO 密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势；因为使用聚簇索引就是为了减少磁盘的IO，放在内存就没用了。
2、插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式；
3、更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置；
4、基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题；

页分裂问题：每一个索引块位置所能存放的数据量是固定的，如果要插入的位置没有足够空间会将索引块数据拆分到两个索引块进行存储，这样在查询会有两个分支从而影响查询的性能，这就是页分裂。
页合并问题：删除索引的时候，如果删除多个数据页的索引的时候，每个索引块不会充分利用，会有剩余空间空闲出来，这个时候可以将多个索引块空间进行页合并，这也是一个浪费IO的操作。

5、聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候

非聚簇索引
数据文件跟索引文件分开存放

覆盖索引

基本介绍
1、如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引
2、不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值
3、不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引

优势
1、索引条目通常远小于数据行大小，如果只需要读取索引，那么mysql就会极大的较少数据访问量
2、因为索引是按照列值顺序存储的，所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多
3、一些存储引擎如MYISAM在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用，这可能会导致严重的性能问题
4、由于INNODB的聚簇索引，覆盖索引对INNODB表特别有用
案例演示
1、当发起一个被索引覆盖的查询时，在explain的extra列可以看到using index的信息，此时就使用了覆盖索引

explain select store_id,film_id from inventory\G

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

           id: 1

  select_type: SIMPLE

        table: inventory

   partitions: NULL

         type: index

possible_keys: NULL

          key: idx_store_id_film_id

      key_len: 3

          ref: NULL

         rows: 4581

     filtered: 100.00

        Extra: Using index

1 row in set, 1 warning (0.01 sec)

2、在大多数存储引擎中，覆盖索引只能覆盖那些只访问索引中部分列的查询。不过，可以进一步的进行优化，可以使用innodb的二级索引来覆盖查询。

mysql> explain select actor_id,last_name from actor where last_name='HOPPER'\G

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

           id: 1

  select_type: SIMPLE

        table: actor

   partitions: NULL

         type: ref

possible_keys: idx_actor_last_name

          key: idx_actor_last_name

      key_len: 137

          ref: const

         rows: 2

     filtered: 100.00

        Extra: Using index

1 row in set, 1 warning (0.00 sec)

优化小细节

当使用索引列进行查询的时候尽量不要使用表达式，把计算放到业务层而不是数据库层

explain select actor_id from actor where actor_id=4;

explain select actor_id from actor where actor_id+1=5;

在索引列使用表达式和不使用表达式type类型完全不一样。

尽量使用主键查询，而不是其他索引，因此主键查询不会触发回表查询
主键查询会进行索引树的查找，这样会提升效率
使用前缀索引

前缀索引实例说明

有时候需要索引很长的字符串，这会让索引变的大且慢，通常情况下可以使用某个列开始的部分字符串，这样大大的节约索引空间，从而提高索引效率，但这会降低索引的选择性，索引的选择性是指不重复的索引值和数据表记录总数的比值，范围从1/#T到1之间。索引的选择性越高则查询效率越高，因为选择性更高的索引可以让mysql在查找的时候过滤掉更多的行。

一般情况下某个列前缀的选择性也是足够高的，足以满足查询的性能，但是对应BLOB,TEXT,VARCHAR类型的列，必须要使用前缀索引，因为mysql不允许索引这些列的完整长度，使用该方法的诀窍在于要选择足够长的前缀以保证较高的选择性，通过又不能太长。

案例演示：

--创建数据表

create table citydemo(city varchar(50) not null);

insert into citydemo(city) select city from city;



--重复执行5次下面的sql语句

insert into citydemo(city) select city from citydemo;



--更新城市表的名称

update citydemo set city=(select city from city order by rand() limit 1);



--查找最常见的城市列表，发现每个值都出现45-65次，

select count(*) as cnt,city from citydemo group by city order by cnt desc limit 10;



--查找最频繁出现的城市前缀，先从3个前缀字母开始，发现比原来出现的次数更多，可以分别截取多个字符查看城市出现的次数

select count(*) as cnt,left(city,3) as pref from citydemo group by pref order by cnt desc limit 10;

select count(*) as cnt,left(city,7) as pref from citydemo group by pref order by cnt desc limit 10;

--此时前缀的选择性接近于完整列的选择性



--还可以通过另外一种方式来计算完整列的选择性，可以看到当前缀长度到达7之后，再增加前缀长度，选择性提升的幅度已经很小了

select count(distinct left(city,3))/count(*) as sel3,

count(distinct left(city,4))/count(*) as sel4,

count(distinct left(city,5))/count(*) as sel5,

count(distinct left(city,6))/count(*) as sel6,

count(distinct left(city,7))/count(*) as sel7,

count(distinct left(city,8))/count(*) as sel8 

from citydemo;



--计算完成之后可以创建前缀索引

alter table citydemo add key(city(7));



--注意：前缀索引是一种能使索引更小更快的有效方法，但是也包含缺点：mysql无法使用前缀索引做order by 和 group by。

使用索引扫描来排序

extra:using filesort:说明mysql无法利用索引进行排序，只能利用排序算法进行排序，会消耗额外的位置

extra:null说明用到索引排序了

使用索引扫描来做排序

创建组合索引的时候默认的索引排序是升序，所以后续用组合索引列进行排序要全部升序或者全部降序才会用到索引；第一列是范围，后续不会用索引，索引会失效；该查询中引用了一个不再索引中的列也不会用索引；

mysql有两种方式可以生成有序的结果：通过排序操作或者按索引顺序扫描，如果explain出来的type列的值为index,则说明mysql使用了索引扫描来做排序

扫描索引本身是很快的，因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列，那么就不得不每扫描一条索引记录就得回表查询一次对应的行，这基本都是随机IO，因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢

mysql可以使用同一个索引即满足排序，又用于查找行，如果可能的话，设计索引时应该尽可能地同时满足这两种任务。

只有当索引的列顺序和order by子句的顺序完全一致，并且所有列的排序方式都一样时，mysql才能够使用索引来对结果进行排序，如果查询需要关联多张表，则只有当orderby子句引用的字段全部为第一张表时，才能使用索引做排序。order by子句和查找型查询的限制是一样的，需要满足索引的最左前缀的要求，否则，mysql都需要执行顺序操作，而无法利用索引排序

--sakila数据库中rental表在rental_date,inventory_id,customer_id上有rental_date的索引

--使用rental_date索引为下面的查询做排序

explain select rental_id,staff_id from rental where rental_date='2005-05-25' order by inventory_id,customer_id\G

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

           id: 1

  select_type: SIMPLE

        table: rental

   partitions: NULL

         type: ref

possible_keys: rental_date

          key: rental_date

      key_len: 5

          ref: const

         rows: 1

     filtered: 100.00

        Extra: Using index condition

1 row in set, 1 warning (0.00 sec)

--order by子句不满足索引的最左前缀的要求，也可以用于查询排序，这是因为所以你的第一列被指定为一个常数



--该查询为索引的第一列提供了常量条件，而使用第二列进行排序，将两个列组合在一起，就形成了索引的最左前缀

explain select rental_id,staff_id from rental where rental_date='2005-05-25' order by inventory_id desc\G

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

           id: 1

  select_type: SIMPLE

        table: rental

   partitions: NULL

         type: ref

possible_keys: rental_date

          key: rental_date

      key_len: 5

          ref: const

         rows: 1

     filtered: 100.00

        Extra: Using where

1 row in set, 1 warning (0.00 sec)



--下面的查询不会利用索引  第一个用了范围查找后续不会使用索引

explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by rental_date,inventory_id\G

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

           id: 1

  select_type: SIMPLE

        table: rental

   partitions: NULL

         type: ALL

possible_keys: rental_date

          key: NULL

      key_len: NULL

          ref: NULL

         rows: 16005

     filtered: 50.00

        Extra: Using where; Using filesort



--该查询使用了两中不同的排序方向，但是索引列都是正序排序的  要么全部升序或者全部降序

explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by inventory_id desc,customer_id asc\G

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

           id: 1

  select_type: SIMPLE

        table: rental

   partitions: NULL

         type: ALL

possible_keys: rental_date

          key: NULL

      key_len: NULL

          ref: NULL

         rows: 16005

     filtered: 50.00

        Extra: Using where; Using filesort

1 row in set, 1 warning (0.00 sec)



--该查询中引用了一个不再索引中的列  索引失效

explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by inventory_id,staff_id\G

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

           id: 1

  select_type: SIMPLE

        table: rental

   partitions: NULL

         type: ALL

possible_keys: rental_date

          key: NULL

      key_len: NULL

          ref: NULL

         rows: 16005

     filtered: 50.00

        Extra: Using where; Using filesort

1 row in set, 1 warning (0.00 sec)

union all,in,or都能够使用索引，但是推荐使用in

explain select * from actor where actor_id = 1 union all select * from actor where actor_id = 2;

explain select * from actor where actor_id in (1,2);

explain select * from actor where actor_id = 1 or actor_id =2;

比较三个查询语句的执行计划 union all 和union 的区别是union会去重，影响性能

set profiling=1;

所以In的性能更好点

范围列可以用到索引
范围列可以用到索引，但是范围列后面的列无法用到索引，索引最多用于一个范围列。
范围列后边的索引会失效。组合索引比如name和age是一个组合索引，name范围比较 即使后面age是等值比较，也不会用age索引，因为name是范围比较会匹配多个数据age,所以没有办法检索age。

强制类型转换会全表扫描
索引列类型转换不会使用索引

create table user(id int,name varchar(10),phone varchar(11));
alter table user add index idx_1(phone);

explain select * from user where phone=13800001234;

不会触发索引

explain select * from user where phone=‘13800001234’;

触发索引

更新十分频繁，数据区分度不高的字段上不宜建立索引

• 更新会变更B+树，更新频繁的字段建议索引会大大降低数据库性能
• 类似于性别这类区分不大的属性，建立索引是没有意义的，不能有效的过滤数据，
• 一般区分度在80%以上的时候就可以建立索引，区分度可以使用 count(distinct(列名))/count(*) 来计算

创建索引的列，不允许为null，可能会得到不符合预期的结果

当需要进行表连接的时候，最好不要超过三张表，因为需要join的字段，数据类型必须一致

join表的时候得原理

查看join buffer大小

能使用limit的时候尽量使用limit

单表索引建议控制在5个以内
索引太多增加或者修改数据的时候会耗费维护成本
单索引字段数不允许超过5个（组合索引）
最左前缀，索引列越多的时候，如果想把索引全部用上就要填充所有索引作为查询列

创建索引的时候应该避免以下错误概念

• 索引越多越好 越多越不易于维护
• 过早优化，在不了解系统的情况下进行优化
  当查询语句比较慢的时候通过explain查询执行计划，然后进行加索引的相应优化措施。

索引优化分析案例

预先准备好数据

SET FOREIGN_KEY_CHECKS=0;

DROP TABLE IF EXISTS `itdragon_order_list`;

CREATE TABLE `itdragon_order_list` (

  `id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主键id，默认自增长',

  `transaction_id` varchar(150) DEFAULT NULL COMMENT '交易号',

  `gross` double DEFAULT NULL COMMENT '毛收入(RMB)',

  `net` double DEFAULT NULL COMMENT '净收入(RMB)',

  `stock_id` int(11) DEFAULT NULL COMMENT '发货仓库',

  `order_status` int(11) DEFAULT NULL COMMENT '订单状态',

  `descript` varchar(255) DEFAULT NULL COMMENT '客服备注',

  `finance_descript` varchar(255) DEFAULT NULL COMMENT '财务备注',

  `create_type` varchar(100) DEFAULT NULL COMMENT '创建类型',

  `order_level` int(11) DEFAULT NULL COMMENT '订单级别',

  `input_user` varchar(20) DEFAULT NULL COMMENT '录入人',

  `input_date` varchar(20) DEFAULT NULL COMMENT '录入时间',

  PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=10003 DEFAULT CHARSET=utf8;



INSERT INTO itdragon_order_list VALUES ('10000', '81X97310V32236260E', '6.6', '6.13', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-08-28 17:01:49');

INSERT INTO itdragon_order_list VALUES ('10001', '61525478BB371361Q', '18.88', '18.79', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-08-18 17:01:50');

INSERT INTO itdragon_order_list VALUES ('10002', '5RT64180WE555861V', '20.18', '20.17', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-09-08 17:01:49');

逐步开始进行优化：
第一个案例：

select * from itdragon_order_list where transaction_id = "81X97310V32236260E";

--通过查看执行计划发现type=all,需要进行全表扫描

explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";



--优化一、为transaction_id创建唯一索引

 create unique index idx_order_transaID on itdragon_order_list (transaction_id);

--当创建索引之后，唯一索引对应的type是const，通过索引一次就可以找到结果，普通索引对应的type是ref，表示非唯一性索引赛秒，找到值还要进行扫描，直到将索引文件扫描完为止，显而易见，const的性能要高于ref

 explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";

 

 --优化二、使用覆盖索引，查询的结果变成 transaction_id,当extra出现using index,表示使用了覆盖索引

 explain select transaction_id from itdragon_order_list where transaction_id = "81X97310V32236260E";

第二个案例

--创建复合索引

create index idx_order_levelDate on itdragon_order_list (order_level,input_date);



--创建索引之后发现跟没有创建索引一样，都是全表扫描，都是文件排序

explain select * from itdragon_order_list order by order_level,input_date;



--可以使用force index强制指定索引

explain select * from itdragon_order_list force index(idx_order_levelDate) order by order_level,input_date;

--其实给订单排序意义不大，给订单级别添加索引意义也不大，因此可以先确定order_level的值，然后再给input_date排序

explain select * from itdragon_order_list where order_level=3 order by input_date;

索引监控

show status like ‘Handler_read%’;
参数解释
如果下面的值很小表名索引的使用率很差

Handler_read_first：读取索引第一个条目的次数
Handler_read_key：通过index获取数据的次数
Handler_read_last：读取索引最后一个条目的次数
Handler_read_next：通过索引读取下一条数据的次数
Handler_read_prev：通过索引读取上一条数据的次数
Handler_read_rnd：从固定位置读取数据的次数
Handler_read_rnd_next：从数据节点读取下一条数据的次数