引子
什么是索引
为什么需要索引
使用索引
索引优化原理
正确使用索引
什么是索引
在关系数据库中，索引是一种单独的、物理层面的对数据库表中一列或多列的值进行排序的一种存储结构; 也称之为key
有以下几种:
unique key
primary key
index key
索引的作用相当于图书的目录，可以根据目录中的页码快速找到所需的内容。
为什么需要索引
思考:一个项目正常运行后,对数据库的操作中,哪些操作是最频繁的?
对数据库的写操作(增加 删除 修改)频繁吗?
对数据库的读操作(查询)频繁吗?
相比较下,对数据的读操作会更加频繁,比例在10:1左右,也就是说对数据库的查询操作是非常频繁的
随着时间的推移,表中的记录会越来越多,此时如果查询速度太慢的话对用户体验是非常不利的
索引是提升查询效率最有效的手段!
简单的说索引的就是用帮我们加快查询速度的
需要注意的是：在数据库中插入数据会引发索引的重建
小白的误区
既然索引如此神奇,那以后只要速度慢了就加索引,
这种想法是非常low的,
索引是不是越多越好,并且有了索引后还要考虑索引是否命中
加上索引后对数据的写操作速度会降低
索引的实现原理
如何能实现加快查询的效果呢?
来看一个例子:
第一版的新华字典共800页,那时没有检字表,每个字的详细信息,随机的罗列在书中,一同学买回来查了一次,在也没用过,因为没有任何的数据结构,查字只能一页一页往后翻,反了两小时没翻着,只能放弃了!
后来出版社发现了这个问题,他们将书中所有字按照拼音音节顺序进行了排序,拼音首字母为a的排在最前,首字母为z的排在最后:
如此一来再不再需要一页一页的去查字了,而是先查看索引,找出字的拼音首字母到索引中进行对照,例如:找搭字其拼音首字母为d,所以直接找到D对应的索引目录,很快就能定位到要找的搭字在79页,查询速度得到数量级的提升!
需要注意的是,原来内容为800页现在因为多了索引数据,整体页数必然增加了
数据库中的索引,实现思路与字典是一致的,需要一个独立的存储结构,专门存储索引数据
本质上索引是通过不断的缩小查询范围来提高查询效率
磁盘IO问题(了解)
数据库的数据最终存储到了硬盘上
机械硬盘由于设计原理,导致查找数据时需要有一个寻道时间与平均延迟时间,常规硬盘寻道为5ms,平均延迟按照每分钟7200转来计算,7200/60 = 120 ; 1000/120/2 = 4ms 总共为9ms,那么9毫秒对于cpu而言已经非常非常的长了,足够做很多运算操作,目前最新的处理器每秒能处理数万亿次运算,拿一个非常垃圾的处理器来举例子,假设处理器每秒处理5亿次计算,每毫秒是50万次运算,9ms可以进行450万次运算,数据库中成千上万的数据,每条数据9ms显然慢到不行!
操作系统预读取(了解)
考虑到磁盘IO是非常高昂的操作，计算机操作系统做了一些优化，当一次IO时，不光把当前磁盘地址的数据，而是把相邻的数据也都读取到内存缓冲区内，因为局部预读性原理告诉我们，当计算机访问一个地址的数据的时候，与其相邻的数据也会很快被访问到。每一次IO读取的数据我们称之为一页(page)。具体一页有多大数据跟操作系统有关，一般为4k或8k，也就是我们读取一页内的数据时候，实际上才发生了一次IO，这个理论对于索引的数据结构设计非常有帮助。
索引数据结构剖析
在字典的例子中我们知道了,索引是独立于真实数据的一个存储结构,这个结构到底是什么样的?
索引最终的目的是要尽可能降低io次数,减少查找的次数,以最少的io找到需要的数据,此时B+树闪亮登场
光有数据结构还不行,还需要有对应的算法做支持,就是二分查找法
有了B+数据结构后查找数据的方式就不再是逐个的对比了,而是通过二分查找法来查找(流程演示)
另外,其实大多数文件系统都是使用B+是来完成的!
应该尽可能的将数据量小的字段作为索引
通过分析可以发现在上面的树中,查找一个任何一个数据都是3次IO操作, 但是这个3次并不是固定的,它取决于树结构的高度,目前是三层,如果要存储新的数据比99还大的数据时,发现叶子节点已经不够了必须在上面加一个子节点,由于树根只能有一个所以,整个数的高度会增加,一旦高度增加则 查找是IO次数也会增加,所以:
应该尽可能的将数据量小的字段作为索引,这样一个叶子节点能存储的数据就更多,从而降低树的高度;
例如:name 和id,应当将id设置为索引而不是name
最左匹配原则*
当b+树的数据项是复合的数据结构，比如(name,age,sex)的时候(多字段联合索引)，b+树会按照从左到右的顺序来建立搜索树，比如当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是F的数据了， 这个是非常重要的性质，即索引的最左匹配特性。
聚集索引*
mysql官方文档原文: 插入了解 或折叠
MySQL为表把它的数据词典信息以.frm文件的形式存在数据库目录里，这对所有MySQL存储引擎都是真的。但 是每个InnoDB表在表空间内的InnoDB内部数据词典里有它自己的条目。当MySQL移除表或数据库，它不得不 删除.frm文件和InnoDB数据词典内的相应条目。这就是为什么你不能在数据库之间简单地移动.frm文件来移 动InnoDB表。
每个InnoDB表有专门索引，被称为clustered index，对行的数据被存于其中。如果你对你的表定义一 个PRIMARY KEY， 主键的索引是集束索引。
如果你没有为表定义PRIMARY KEY，MySQL拾取第一个仅有NOT NULL列的UNIQUE索引作为主键，并 且InnoDB把它当作集束索引来用。如果表中没有这样一个索引，InnoDB内部产生一个集束索引，其中 用InnoDB在这样一个表内指定给行的行ID来排序行。行ID是一个6字节的域，它在新行被插入的时候简单地增加。因此被行ID排序的行是物理地按照插入顺序排的。
通过集束索引访问一个行是较快的，因为行数据是在索引搜索引导的同一页面。如果表是巨大的，当对比于传 统解决方案，集束索引构架经常节约磁盘I/O。(在许多数据库，数据传统地被存在与索引记录不同的页)。
在InnoDB中，非集束索引里的记录(也称为第二索引)包含对应行的主键值。InnoDB用这个 主键值来从集束索 引中搜索行。注意，如果主键是长的，第二索引使用更多空间。
简单总结:
聚焦索引的特点:
? 叶子节点保存的就是完整的一行记录,如果设置了主键,主键就作为聚集索引,
? 如果没有主键,则找第一个NOT NULL 且QUNIQUE的列作为聚集索引,
? 如果也没有这样的列,innoDB会在表内自动产生一个聚集索引,它是自增的
? 聚集索引中包含了完整的记录
辅助索引*
除了聚集索引之外的索引都称之为辅助索引或第二索引,