MySQL学习笔记(六)：索引

 

本文主要介绍MySQL 中关于索引的一些问题，例如：索引的做用；怎么建立索引；设计索引的原则；怎么优化索引等等。

 

一：索引概述

索引通常是经过排序，而后查找时能够二分查找，这一特色来达到加速查找的目的的。

全部的MySQL列类型都能建立索引，良好设计的因此可以很好地提升查询的性能，但若是索引过多，因为每次更新操做都会对索引进行更新，反而会影响到数据库的总体性能。于是，遵循必定的原则，设计合适的索引是很是重要的。

(1)：建立索引的语法

CREATE [UNIQUE|FULLTEXT|SPQTIAL] INDEX index_name [USING index_type] ON table_name(col_name)

例子：建了一张user表，有属性 name, age, address, 下面图能够看出没创建索引和创建索引时查询的区别。

 

二：设计索引的几个原则

(1): where子句中的列比select中的列更适合作索引。

(2): 选择那些基数大的列，这要的索引效果更好，这要索引才能很好地区分不一样值。

(3): 使用短索引，例如一个char(200)的列，若是前20个字符就能很好的区分不一样的值时，就不必对整个列进行索引，这样能够大大的减小索引的存储空间。

(4): 不要过分索引，只创建所需的索引。过多的索引会浪费磁盘空间，下降写的性能，也会给查询优化带来更多的工做，让MySQL选择不到最好的索引。

(5): InnoDB尽可能本身指定主键：InnoDB 引擎存储的表会按照必定的顺序保存，例如主键，惟一索引，若是都没有则会自动生成一个内部列，按照这些进行访问是最快的，因此InnoDB尽可能本身指定主键。当有多个列能够做为主键时，选择最常做为访问条件的列做为主键。

      例子：InnoDB没建立索引，但创建了主键，会用主键进行查询。

 

三：BTREE索引和HASH索引

MyISAM 和 InnoDB 默认建立的是BTREE索引，MEMORY引擎默认建立的是Hash索引，BTREE 用于全值匹配，匹配列前缀，范围匹配时很是有效。HASH索引存储的是hash值，而且是全部索引列的Hash值，只能用于精确匹配。

BTREE 的几个限制：

(1). 必须按照索引的最左列开始查找

(2). 不能跳过索引中的列

(3). 某个列使用了范围查询，其右边的列都没法使用索引。

 索引列的位置顺序，很是重要，写ＳＱＬ时须要尤为注意。

 

HASH索引的几个限制：

(1). hash索引只存储哈希值和行指针，不存储字段值，结构紧凑。

(2). 数据不是按照索引值顺序存储的，因此没法用于排序。

(3). 不支持部分索引列的匹配查找，由于hash值是用全部的索引列计算的。

(4). 只支持精确查找

 

四：索引的优化

在遵循索引的设计原则后，设计索引和编写SQL时还须要注意索引使用时的几个特色：

(1). 前缀特性 : 当建立了多列索引时，只要用到了前面的列，索引就会起做用。例如建立了两列索引(a,b) ，当where条件语句中仅出现了a，索引也会被使用，但仅仅出现了b,索引将不会被使用。

(2). 使用like查询时，%不能出如今第一个字符，应该是 “ 常量 + %”，这样索引才可能会起做用。

(3). 对大文本进行搜索时，使用全文索引而不是使用 like '%...%, 更好的方法是在BTREE的基础上创建伪Hash索引，仅仅须要对这列计算hash值再存储，能够节省空间。缺陷是须要维护hash值，能够用触发器维护。

(4). 用or分割开的条件，若是or前面的列有索引，后面的列没有索引，那么涉及到索引都不会被用到。 

(5). 若是列类型是字符串，记得where条件中把字符串常量值用引号引发来。

 

查看索引的使用状况，用 show status like 'Handle_read%' 查看Handle_read_key(值大说明索引获得了很好的使用，反之亦然) 和 Handle_read_rnd_next(值很大说明进行了大量的全盘扫描，索引没获得很好地使用) 的值。