算法可视化: https://www.cs.usfca.edu/~galles/visualization/Algorithms.html
二叉查找数
左子树的键值总是小于根的键值,右子树的键值总是大于根的键值
如:6 3 7 2 5 8
图片.png
当二叉查找树左右不平衡时,查找效率就会变低
如 : 2 3 5 7 6 8
图片.png所以产生了新的查找树,即 平衡二叉树(AVL树)
平衡二叉树
首先符合二叉查找树的定义,其次必须满足任何节点的两个子树的高度最大差为1。
维护一棵平衡二叉树的代价是非常大的,需要1次或多次左旋和右旋来得到插入或更新后树的平衡性
B+ 树
B+树是为磁盘或其他直接存取辅助设备设计的一种平衡查找树。在B+树中,所有记录节点都是按键值的大小顺序存放在同一层的叶子节点上,由各叶子节点指针进行连接
一棵 m 阶的 B+ 树需要满足下列条件:
1)、每个分支结点最多有 m 棵子树(子结点)
2)、非叶根结点至少有两棵子树,其他每个分支结点至少有 [m/2]
棵子树
3)、结点的子树个数与关键字个数相等
4)、所有叶结点包含全部关键字及指向相应记录的指针,而且叶结点中将关键字按大小顺序排列,并且相邻叶结点按大小顺序相互链接起来。
5)、所有分支结点(可看成是索引的索引)中仅包含它的各个子结点(即下一级的索引块) 中关键字的最大值及指向其子结点的指针
B+树插入的三种情况:
Leaf Page 满 | Index Page 满 | 操作 |
---|---|---|
N | N | 直接将记录插入到叶子节点 |
Y | N | 1、拆分Leaf Page 2、将中间节点放入Index Page中 3、小于中间节点的记录被放在左边 4、大于等于中间节点的记录被放在右边 |
Y | Y | 1、拆分Leaf Page 2、小于中间节点的记录放左边 3、大于等于中间节点的记录放右边 4、拆分Index Page 5、小于中间节点的记录放左边 6、大于中间节点的记录放右边 7、中间节点放入上一层Index Page |
B+树删除的三种情况:
叶子节点小于填充因子 | 中间节点小于填充因子 | 操作 |
---|---|---|
N | N | 直接将记录从叶子节点删除,如果该节点还是Index Page的节点,用该节点的右侧节点代替 |
Y | N | 合并叶子节点和它的兄弟节点,同时更新Index Page |
Y | Y | 1、合并叶子节点和它的兄弟节点 2、更新Index Page 3、合并Index Page和它的兄弟节点 |
聚集索引
聚集索引(clustered index)就是按照每张表的主键构造一棵B+树,同时叶子节点中存放的即为整张表的行记录数据,也将聚集索引的叶子节点称为数据页。聚集索引的这个特性决定了索引组织表中数据也是索引的一部分。同B+树数据结构一样,每个数据页都通过一个双向链表来进行链接。
由于实际的数据页只能按照一棵B+树进行排序,因此每张表只能拥有一个聚集索引。在多数情况下,查询优化器倾向于采用聚集索引。因为聚集索引能够在B+树索引的叶子节点上直接找到数据。此外,由于定义了数据的逻辑顺序,聚集索引能够特别快地访问针对范围值的查询。查询优化器能够快速发现某一段范围的数据页需要扫描。
辅助索引
对于辅助索引(Secondary Index,也称非聚集索引),叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外,每个叶子节点中的索引行中还包含了一个书签(bookmark)。该书签用来告诉InnoDB存储引擎哪里可以找到与索引相对应的行数据。由于InnoDB存储引擎表是索引组织表,因此InnoDB存储引擎的辅助索引的书签就是相应行数据的聚集索引键
InnoDB
B+树索引的管理
# 查看索引
show index from [table_name]
# 结果列含义
Non_unique:非唯一的索引
Key_name:索引的名字
Seq_in_index:索引中该列的位置
Column_name:索引列的名称
Collation:列以什么方式存储在索引中。可以是A或NULL。B+树索引总是A,即排序的。如果使用了Heap存储引擎,并且建立了Hash索引,这里就会显示NULL了。因为Hash根据Hash桶存放索引数据,而不是对数据进行排序。
Cardinality:非常关键的值,表示索引中不重复记录数量的预估值。Cardinality除以表的行数(Cardinality/n_rows_in_table)应尽可能接近1,Cardinality值如果非常小,那么用户需要考虑是否可以删除此索引。
Sub_part:是否是列的部分被索引。
Packed:关键字如何被压缩。如果没有被压缩,则为NULL。
Null:是否索引的列含有NULL值。
Index_type:索引的类型。InnoDB存储引擎只支持B+树索引,所以都是BTREE。
Comment:注释。
Cardinality :
Cardinality值非常关键,优化器会根据这个值来判断是否使用这个索引。但是这个值并不是实时更新的,即并非每次索引的更新都会更新该值,因为这样代价太大了。因此这个值是不太准确的,只是一个大概的值。
如果需要更新索引Cardinality的信息,可以使用ANALYZE TABLE命令,如:
ANALYZE TABLE [table_name]
OLTP 与 OLAP :https://www.jianshu.com/p/b1d7ca178691
联合索引
联合索引也是一颗B+树,键值大于1
图片.png如 (a,b)的联合索引,键以a来进行排序,b则在a的维度下排序,所以联合索引的顺序也很重要
查询SELECT * FROM TABLE WHERE a=xxx andb=xxx 可以走该索引
SELECT * FROM TABLE WHERE a=xxx 也可以走该索引
SELECT * FROM TABLE WHERE b=xxx 不走索引
覆盖索引
InnoDB存储引擎支持覆盖索引(covering index,或称索引覆盖),即从辅助索引中就可以得到查询的记录,而不需要查询聚集索引中的记录。使用覆盖索引的一个好处是辅助索引不包含整行记录的所有信息,故其大小要远小于聚集索引,因此可以减少大量的IO操作。
使用情况:
只查询主键信息
对于某些统计问题 : select count(*) from table_name
网友评论