mysql数据库索引系列专题

1，现状

mysql数据库对我来说已经比较熟悉了，轻松建表查表配合各种花式查询，但是要说了解，那可能还差很远，基本功能会用，但是不精，高级功能知道，但是不知道原理，总而言之，这对我来说基本就是黑盒子，能用但是用不好，知道但是不了解。就拿索引来说，以前是各种索引建一堆，不管用上用不上。后来一看，果然，一个都没用上！今天就拿索引开刀吧.

2，先上调试神器explain

使用方法：

explain 你的查询语句

#比如explain select * from test;

你就能得到如下几个字段：

• id: 查询的序列号

• select_type: 查询的类型，主要是区别普通查询和联合查询、子查询之类的复杂查询

  • SIMPLE：查询中不包含子查询或者UNION
  • 查询中若包含任何复杂的子部分，最外层查询则被标记为：PRIMARY
  • 在SELECT或WHERE列表中包含了子查询，该子查询被标记为：SUBQUERY

• table: 输出结果集的表

• type: 访问类型，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL

  • ALL: 扫描全表
  • index: 扫描全部索引树
  • range: 扫描部分索引，索引范围扫描，对索引的扫描开始于某一点，返回匹配值域的行，常见于between、<、>等的查询
  • ref: 使用非唯一索引或非唯一索引前缀进行的查找
  • （eq_ref和const的区别：）
  • eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描
  • const, system: 单表中最多有一个匹配行，查询起来非常迅速，例如根据主键或唯一索引查询。system是const类型的特例，当查询- 的表只有一行的情况下， 使用system。
  • NULL: 不用访问表或者索引，直接就能得到结果，如select 1 from test where 1

• key: 显示MySQL实际决定使用的索引。如果没有索引被选择，是NULL

• possible_keys:表示查询时，可能使用的索引

• key_len: 使用到索引字段的长度，长度单位应该是字节吧？我猜
  注：key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的。

• ref: 显示哪个字段或常数与key一起被使用

• rows: 这个数表示mysql要遍历多少数据才能找到，表示MySQL根据表统计信息及索引选用情况，估算的找到所需的记录所需要读取的行数，在innodb上可能是不准确的

• filtered:按表条件过滤的行百分比。表示返回结果的行数占需读取行数的百分比，Filtered列的值越大越好，Filtered列的值依赖于统计信息。

• Extra: 执行情况的说明和描述。包含不适合在其他列中显示但十分重要的额外信息。

  • 　　    Using index：表示使用索引，如果只有 Using index，说明他没有查询到数据表，只用索引表就完成了这个查询，这个叫覆盖索引。

  •    　　 Using where：表示从数据表中使用条件查询（和using index相对），如果不读取表的所有数据，或不是仅仅通过索引就可以获取所有需要的数据，则会出现 Using where。

注意，explain不能做什么呢？

• EXPLAIN不会告诉你关于触发器、存储过程的信息或用户自定义函数对查询的影响情况
• EXPLAIN不考虑各种Cache
• EXPLAIN不能显示MySQL在执行查询时所作的优化工作
• 部分统计信息是估算的，并非精确值
• EXPALIN只能解释SELECT操作，其他操作要重写为SELECT后查看执行计划。

3，索引的类型

1）单列普通索引，非主键，非唯一列的索引，以表的单个列字段创建的索引。

2）联合普通索引（又叫组合索引），非主键，非唯一列的索引，以表的多个列字段组合创建的索引，在查询条件使用索引的从左字段顺序才会生效，遵循最左匹配原则。

所谓最左匹配原则就是这样的：

先创建一个test数据表：

create table test(
a int not null AUTO_INCREMENT ,
b int,
c int,
d int,
PRIMARY key (`a`),
key index_abc(b,c,d)
)engine=InnoDB default charset=utf8;

然后你会发现：

1）具体查询
EXPLAIN  select * from test where  b=1 and c=2 and d=3 ;
EXPLAIN  select * from test where  b=1 and  d=3 and c=2 ;
EXPLAIN  select * from test where d=3 and  c=2 and b=1;
##不管b，c，d顺序如何，以上三个查询都用到了联合普通索引，并且只通过索引，未通过数据表就可以拿到想要的数据
2）范围查询
EXPLAIN  select * from test where  b>1 and c>1 and d>1 ;
EXPLAIN  select * from test where d>1 and  c>1 and b>1;
#说好的最左呢？为什么两条语句的查询状况一样？别人查了一下资料发现：mysql查询优化器会判断纠正这条sql语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。

EXPLAIN  select * from test where  b>1 and d>1 ;
EXPLAIN  select * from test where  c>1 and d>1;
#这两个查询就不一样了，虽然都是使用了数据表和索引，但是效率有差别，第一个，type是range，key_len是5，rows是1，fitered是33.33（意思是如果读取了100条数据，有33条会被当成结果返回），而第二条查询，type是index，key_len是15，rows是6，fitered是16.67（读取100条数据，只有16条能被当成结果返回）

3）排序：
EXPLAIN  select * from test order by b ;
EXPLAIN  select * from test order by c ;
#这两个查询语句都用到了我们创建 bcd索引，但是两个语句执行还是有所不同，第二个的extra项目中除了有using index还多了一个Using filesort，Using filesort 是一种速度很慢的外部排序，说明一个问题，虽然第二个查询看起来用了索引，但是很明显不是我们想要的效果。

4）联合查询

  explain select * from test where b>2 ;
  explain select * from test where b=1 and c>2 and d=1 ;
  explain select * from test where d =1;

  #第一条，部分使用了abc索引，除此以外，extra中还用了Using where; Using index，  key_len、rows和filtered分别是5，1，和100

  #第二条，部分使用了abc索引，据说只有b和c用到了索引，d完全用不到索引，但我个人觉得c可能也只是用到了部分索引，所以key_len、rows和filtered分别是10，4，和16.67，当然extra和上一条一样

  #第三条，虽然key中写明了inde_abc但是type是index,意思是扫描全部索引树，key_len、rows和filtered分别是15，6，和16.67

  #所以，由此可以得出结论，通过最左匹配原则你可以定义一个联合索引，值得注意的是，当遇到范围查询(>、<、between、like)就会停止匹配。据说这是因为btree的原理决定的，可是我貌似并不知道btree的原理，哭，改天一定补上

  #所以，如果有个表你需要这样查，SELECT * FROM DB.TB WHERE ID=2222 AND FID IN (9,8,3,13,38,40) ORDER BY INVERSE_DATE LIMIT 0, 5，那么你需要两个联合普通索引，IDX（ID,FID ,INVERSE_DATE）和IDX（ID,INVERSE_DATE）。详见这里

 3）唯一索引，类似于主键，要求索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。

#对于一个存储用户id，用户名，用户密码的表，可以在用户名上创建唯一索引，一方面是为了查询快，另一方面能防止用户名重复带来的一系列问题。

CREATE unique INDEX index_name ON t_user(user_name)；#创建独立索引
select * from t_user where user_name='admin' and user_state != 999；   #使用独立索引进行查询type为const，filtered是100

4）主键索引，是一种特殊的唯一索引，一个表必须有且只能有一个主键，不允许有空值，主键列的值必须唯一，一般是在建表的时候同时创建主键索引。

5）全文索引,主要用来查找文本中的关键字，而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同，它更像是一个搜索引擎，而不是简单的where语句的参数匹配。fulltext索引配合match against操作使用，而不是一般的where语句加like。它可以在create table，alter table ，create index使用，不过目前只有char、varchar，text 列上可以创建全文索引。值得一提的是，在数据量较大时候，现将数据放入一个没有全局索引的表中，然后再用CREATE index创建fulltext索引，要比先为一张表建立fulltext然后再将数据写入的速度快很多。

 

4，索引无法加速的情况

（1）insert操作

insert的过程是，先把数据插入到表中，然后再把数据插入到相关索引中，如果这个表有5个索引，那么就得维护这5个索引，不管这个插入的数据是否为NULL值。

所以，索引个数越多，对于insert操作来说，维护的成本就越大，插入一条数据的速度也就越慢。

如果发现插入速度很慢，可以检查一下是否这个表的索引太多了。

把数据插入索引的过程中，为了维护索引中字段的顺序，会先在索引中查找这个值，如果能找到，就把这个值查到后面空闲的地方，如果没有找到，就先把值加入到叶子节点，然后在分支节点中新增这个值 和 指向叶子节点的指针（就是一个地址）。

在这个过程中，如果某个页满了，还要新申请一个空的页，把满的页拆分开，把一半的索引数据放到空闲页中，而且为了保证数据的一致性（这个插入操作是并发的，可能有几十上百个线程同时进行），会给相关的索引页加上闩锁（一种更低级别的内存锁）。

如此看来，这个过程的开销是很大的。

（2）delete操作

delete操作刚好和isnert相反，当删除一条数据时，会把这条数据涉及到的多个索引中的数据删除。

比如：A表包含字段 ID，name，age，memo，biz_date，storeID，employeeID，update_date，等字段，在name、age、biz_date、storeID、employeeID字段上分别创建了索引，也就是总共有5个索引。

现在运行 delete from A where ID = 100

就得把ID=100的这条数据，在各个索引中删掉，但是开销要比insert小。

（3）update操作

这个操作不同于insert，delete，只有当update的这个字段，涉及到索引时，才需要维护索引，相对来说开销要小一些。

 5,索引使用注意事项

使用索引时，有以下一些技巧和注意事项：
1.索引不会包含有null值的列
只要列中包含有null值都将不会被包含在索引中，复合索引中只要有一列含有null值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为null。
2.使用短索引
对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个char(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。
3.索引列排序
查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。
4.like语句操作
一般情况下不推荐使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。
5.不要在列上进行运算
这将导致索引失效而进行全表扫描，