索引扫盲

索引

是对数据库中一列或多列的值进行排序的一种结构

索引的种类：

• 普通索引
• 唯一索引
• 全文索引 - 替代 Like 模糊查询
• B-Tree 索引 - MyISAM,InnoDB
• Hash 索引 - Memory 存储引擎

B-Tree 索引

概述

Mysql数据库中使用最频繁的索引类型，基本所有存储引擎都支持BTree索引。正是其优异的检索表现，才使其有这样的地位。

存储结构

是使用B-Tree的数据结构来存储数据，但是不同的存储引擎在使用这种数据结构来存储数据时会进行不同的修改，例如MyISAM和InnoDB使用的都是B+Tree结构。但是与B-Tree不同的是，它把所有的数据都存到了叶子节点上。并且所有的叶子节点相互连通，加快相邻数据节点的检索。并且存储策略也进行了修改。

MyISAM 非聚集索引

MyISAM的存储策略是，所有的叶子节点存储的并不是真实的数据，而是数据节点的地址。通过地址检索真正的数据，索引文件与数据文件分离存储。这样的存储策略称为非聚集索引。需要注意的是它的主索引与辅助索引的键值不能重复

它的检索策略是检索B-Tree找到对应的数据节点，拿到数据的物理地址，然后去访问。

非聚集索引

InnoDB 聚集索引

InnoDB的存储策略是叶子节点即数据节点，索引文件与数据文件一起存储。它的主索引存储的是完整的数据记录集合也可以看成索引的索引，而辅助索引存储的是真实的数据，这个数据是数据表中的主键。InnoDB的数据文件本身就是主键索引文件，这样的索引被称为聚集索引。且一个表只能有一个聚集索引

检索的时候它通过主键来确定数据。这样的数据文件本身就是主键索引的存储结构。所以称它为聚集索引

聚集索引

Hash 索引

概述及存储结构

主要就是通过Hash算法（常见的Hash算法有直接定址法、平方取中法、折叠法、除数取余法、随机数法），将数据库字段数据转换成定长的Hash值，与这条数据的行指针一并存入Hash表的对应位置；如果发生Hash碰撞（两个不同关键字的Hash值相同），则在对应Hash键下以链表形式存储。

检索算法：在检索查询时，就再次对待查关键字再次执行相同的Hash算法，得到Hash值，到对应Hash表对应位置取出数据即可，如果发生Hash碰撞，则需要在取值时进行筛选。目前使用Hash索引的数据库并不多，主要有Memory等。

一般来说，索引的检索效率非常高，可以一次定位，不像B-Tree索引需要进行从根节点到叶节点的多次IO操作。

弊端

• 查询：只能进行数据等值查询,不能进行范围或者非精确查询,因为hash算法的原因。不同值出现的结果相差很大。所以hash的优势也就不在
• 排序：hash算法不能排序，因为hash算法的原因,经过hash算法的数值的大小不可确定。排序没有意义
• 检索表数据：hash算法同样不能避免表数据的扫描，因为会发生hash碰撞的原因，当该情况发生的时候，还显示需要去表中检索数据来确认数据
• hash碰撞：当数据中出现大量hash碰撞的时候，就需要进行多次的表数据扫描来确认数据。这样的情况，效率不一定有B+Tree的效率高。如同字典多个相同值因为hash碰撞的原因，存到了hash表的同一位置。比如10,77,256,347,652这些页中的数据，在一个hash表的位置存储，但你无法确认哪个数据是你需要的，你需要一个一个去排查。无形中又是一个大工程，不一定效率高于BTree。
• 索引查询限制：hash索引不能通过部分索引检索数据，因为hash排列是对整个索引列进行hash算法排列的。部分索引经过hash排列到的位置是没有任何意义的。

Full-Text 索引

概述

全文索引，目前MySQL中只有MyISAM存储引擎支持，并且只有CHAR、VARCHAR、TEXT类型支持。它用于替代效率较低的LIKE模糊匹配操作，而且可以通过多字段组合的全文索引一次性全模糊匹配多个字段。

存储结构

Full-Text索引使用的也是B-Tree存储，但是不同的是换了一种算法。它是先对数据进行列数据分割(一般每4个字节)，然后对分割后的数据再进行索引。索引文件存储的是数据分割前的字符串，以及分割后的索引信息。数据文件存储的是各分割数据的信息，以及在原字符串中的位置。

索引的利弊

利端：

• 减少不相关数据的IO检索次数。所以可以明显的提交数据的检索效率
• 降低数据库排序的成本。如果索引后文件存储的顺序和取出后数据的存储数据一致(聚集索引)。那么就省去了数据库再对数据排序的操作，同样分组操作时先排序后分组，这样就省去了分组的排序操作。提升了CPU资源的消耗。

弊端：

• 索引会带来DML操作的索引重排后果。数据变更会带来IO上的负担以及索引重排的计算负担
• 索引会占用一部分的存储空间。随着数据量的增大，资源消耗愈发的明显。

判断是否适合建立索引

适合

• 经常进行DQL操作的数据列
• 字段列经常出现在where检索条件及连接条件中。
• 数据表的量增大时
• 数据不经常变更

不适合

• 经常进行DML操作的
• 数据里很小时
• 唯一性太差的字段，即便经常被检索。
• 数据经常变更

官方建议

在INNODB中， 所有的第二索引(非主键索引)都会包含主键。所以官方建议，主键索引不要选择在比较长的字段上， 最好就是INT类型的