1.**每个索引就是一颗B+树**,二级索引不包含行记录的全部数据
2.叶子节点除了包含键值以外,每个叶子节点中的索引行中还包含了一个书签( bookmark)
3.B+平衡树是一颗查找树,B+树的叶子节点用来放数据的,并且所有叶子节点位于同一层.
叶子节点放什么数据呢?
1.索引自然是要放的,因为B+树的作用本来就是就是为了快速检索数据
2.数据库中的表数据才是我们真正需要的数据,索引只是辅助数据
3.B+ Tree 是基于 B Tree 和叶子节点顺序访问指针进行实现,它具有 B Tree 的平衡性,并且通过顺序访问指针来提高区间查询的性能
1.InnoDB中使用了聚集索引,就是将表的主键用来构造一棵B+树,并且将整张表的行记录数据存放在该B+树的叶子节点中。也就是所谓的索引即数据,数据即索引。
2.由于聚集索引是利用表的主键构建的,所以每张表只能拥有一个聚集索引。
3.聚集索引的叶子节点就是数据页。换句话说,数据页上存放的是完整的每行记录。因此聚集索引的一个优点就是:通过过聚集索引能获取完整的整行数据。另一个优点是:对于主键的排序查找和范围查找速度非常快。
4.如果我们没有定义主键呢?MySQL会使用唯一性索引,没有唯一性索引,MySQL也会创建一个隐含列RowID来做主键,然后用这个主键来建立聚集索引。
每建立一个索引,就有一颗B+树,叶子节点并不包含行记录的全部数据
1.聚簇索引只能在**搜索条件是主键值**时才能发挥作用,因为B+树中的数据都是按照主键进行排序的
2.如果我们想以别的列作为搜索条件怎么办?我们一般会建立多个索引,这些索引被称为辅助索引/二级索引。
3.叶子节点除了包含键值以外,每个叶子节点中的索引行中还包含了一个书签( bookmark)。该书签用来告诉InnoDB存储引擎哪里可以找到与索引相对应的行数据。因此InnoDB存储引擎的辅助索引的书签就是相应行数据的聚集索引键。
1.辅助索引的存在并不影响数据在聚集索引中的组织,因此每张表上可以有多个辅助索引
2.当通过辅助索引来寻找数据时,InnoDB存储引擎会遍历辅助索引并通过叶级别的指针获得指向主键索引的主键,然后再通过主键索引(聚集索引)来找到一个完整的行记录。这个过程也被称为 回表.
也就是根据辅助索引的值查询一条完整的用户记录需要使用到2棵B+树----一次辅助索引,一次聚集索引。
1.如果把完整的用户记录放到叶子节点是可以不用回表,但是太占地方了,相当于每建立一棵B+树都需要把所有的用户记录再都拷贝一遍,这就有点太浪费存储空间了。而且每次对数据的变化要在所有包含数据的索引中全部都修改一次,性能也非常低下。
2.很明显,回表的记录越少,性能提升就越高,需要回表的记录越多,使用二级索引的性能就越低,甚至让某些查询宁愿使用全表扫描也不使用二级索引。
什么时候采用全表扫描的方式,什么时候使用采用二级索引 + 回表的方式去执行查询呢?
1.这个就是查询优化器做的工作,查询优化器会事先对表中的记录计算一些统计数据,然后再利用这些统计数据根据查询的条件来计算一下需要回表的记录数,需要回表的记录数越多,就越倾向于使用全表扫描,反之倾向于使用二级索引 + 回表的方式。
上面的描述中,隐藏了一个条件,那就是构建索引的字段只有一个,实际生产环境中,构建的索引字段是多个字段
将表上的多个列组合起来进行索引我们称之为联合索引或者复合索引
注意:
1.建立联合索引只会建立1棵B+树
2.多个列分别建立索引会分别以每个列则建立B+树,有几个列就有几个B+树
举例:引出最佳左前缀法则
如果是index(note,b)在索引构建上,包含了两个意思
1.先把各个记录按照note列进行排序
2.在记录的note列相同的情况下,采用b列进行排序
//从原理可知,为什么有最佳左前缀法则,就是这个道理
1.B+树的查找次数,取决于B+树的高度,在生产环境中,B+树的高度一般为3、4层,故需要3、4次的IO查询。
2.所以在InnoDB存储引擎内部自己去监控索引表,如果监控到某个索引经常用,那么就认为是热数据,然后内部自己创建一个hash索引,称之为自适应哈希索引
3.创建以后,如果下次又查询到这个索引,那么直接通过hash算法推导出记录的地址,直接一次就能查到数据,比重复去B+tree索引中查询三四次节点的效率高了不少。
//注意,对于自适应哈希索引仅是数据库自身创建并使用的,我们并不能对其进行干预。
4.哈希索引只能用来搜索等值的查询,如 SELECT* FROM table WHERE index co=xxx。而对于其他查找类型,如范围查找,是不能使用哈希索引的
1.将存储于数据库中的整本书或整篇文章中的任意内容信息查找出来的技术.
2.它可以根据需要获得全文中有关章、节、段、句、词等信息
3.也可以进行各种统计和分析。我们比较熟知的Elasticsearch、Solr等就是全文检索引擎
倒排索引
将文档中包含的关键字全部提取处理,然后再将关键字和文档之间的对应关系保存起来,最后再对关键字本身做索引排序.
用户在检索某一个关键字是,先对关键字的索引进行查找,再通过关键字与文档的对应关系找到所在文档。
1.从InnoDB 1.2.x版本开始,InnoDB存储引擎开始支持全文检索,对应的MySQL版本是5.6.x系列.
2.不过MySQL从设计之初就是关系型数据库,存储引擎虽然支持全文检索,整体架构上对全文检索支持并不好而且限制很多,比如每张表只能有一个全文检索的索引,不支持没有单词界定符( delimiter)的语言,如中文、日语、韩语等。
1.一个索引就是一个B+树,索引让我们的查询可以快速定位和扫描到我们需要的数据记录上,加快查询的速度。
2.一个select查询语句在执行过程中一般最多能使用一个二级索引,即使在where条件中用了多个二级索引。
1.这里所说的类型大小指的就是该类型表示的数据范围的大小.
2.因为数据类型越小,在查询时进行的比较操作越快
3.数据类型越小,索引占用的存储空间就越少,在一个数据页内就可以放下更多的记录,从而减少磁盘/0带来的性能损耗,也就意味着可以把更多的数据页缓存在内存中,从而加快读写效率
这个建议对于表的主键来说更加适用.
1.创建索引应该选择选择性/离散性高的列.
2.索引的选择性/离散性是指,不重复的索引值(也称为基数,cardinality)和数据表的记录总数(N)的比值,范围从1/N到1之间。索引的选择性越高则查询效率越高,因为选择性高的索引可以让MySQL在查找时过滤掉更多的行.
3.唯一索引的选择性是1,这是最好的索引选择性,性能也是最好的。
1.针对blob、text、很长的varchar字段,mysql不支持索引他们的全部长度,需建立前缀索引。
//缺点
2.前缀索引是一种能使索引更小、更快的有效办法,但另一方面也有其缺点MySQL无法使用前缀索引做ORDER BY和GROUP BY,也无法使用前缀索引做覆盖扫描。
3.有时候后缀索引 (suffix index)也有用途(例如,找到某个域名的所有电子邮件地址)
MySQL原生并不支持反向索引,但是可以把字符串反转后存储,并基于此建立前缀索引。可以通过触发器或者应用程序自行处理来维护索引。
1.就是说,只为出现在WHERE 子句中的列、连接子句中的连接列创建索引。
索引列的顺序:
1.正确的顺序依赖于使用该索引的查询,并且同时需要考虑如何更好地满足排序和分组的需要。
2.在一个多列B-Tree索引中,索引列的顺序意味着索引首先按照最左列进行排序,其次是第二列,等等。
3.所以,索引可以按照升序或者降序进行扫描,以满足精确符合列顺序的ORDER BY、GROUP BY和DISTINCT等子句的查询需求。
多列索引的经验法则:
1.将选择性最高的列放到索引最前列。
当不需要考虑排序和分组时,将选择性最高的列放在前面通常是很好的。
这时候索引的作用只是用于优化WHERE条件的查找。
满足的条件如下视为三星:
1.索引将相关的记录放到一起则获得一星 (比重27%)
2.如果索引中的数据顺序和查找中的排列顺序一致则获得二星(排序星) (比重27%)
3.如果索引中的列包含了查询中需要的全部列则获得三星(宽索引星) (比重50%)
一星:
一星的意思就是:如果一个查询相关的索引行是相邻的或者至少相距足够靠近的话,必须扫描的索引片宽度就会缩至最短,也就是说,让索引片尽量变窄,也就是我们所说的索引的扫描范围越小越好。
二星(排序星) :
在满足一星的情况下,当查询需要排序,group by、 order by,如果查询所需的顺序与索引是一致的(索引本身是有序的),是不是就可以不用再另外排序了,一般来说排序可是影响性能的关键因素。
三星(宽索引星) :
在满足了二星的情况下,如果索引中所包含了这个查询所需的所有列(包括 where 子句和 select 子句中所需的列,也就是覆盖索引),这样一来,查询就不再需要回表了,减少了查询的步骤和IO请求次数,性能几乎可以提升一倍。
设计三星索引实战
CREATE TABLE customer (
cno INT,
lname VARCHAR (10),
fname VARCHAR (10),
sex INT,
weight INT,
city VARCHAR (10)
);
CREATE INDEX idx_cust ON customer (city, lname, fname, cno);
-- 对于如下的查询,是三星索引
select cno,
fname
from customer
where lname=’xx’
and city =’yy’
order by fname;
解释:
第一颗星:所有等值谓词的列,是组合索引的开头的列,可以把索引片缩得很窄,符合。
第二颗星:order by的fname字段在组合索引中且是索引自动排序好的,符合。
第三颗星:select中的cno字段、fname字段在组合索引中存在,符合。