MySql

1.索引

mysql索引默认使用的是B+Tree(B-树的变种版)。也可以使用HASH表。

mysql二维查询 mysql二叉树查询_平衡树

二叉树:

二叉树又称二叉搜索树,二叉排序树,特点如下:

  1. 左子树上所有结点值均小于根结点
  2. 右子树上所有结点值均大于根结点
  3. 结点的左右子树本身又是一颗二叉查找树
  4. 二叉查找树中序遍历得到结果是递增排序的结点序列

mysql二维查询 mysql二叉树查询_mysql二维查询_02

基于二叉查找树的这种特点,我们在查找某个节点的时候,可以采取类似于二分查找的思想,快速找到某个节点。n 个节点的二叉查找树,正常的情况下,查找的时间复杂度为 O(logn)

下图是二叉树的缺点:当数据是单边递增/递减 进行插入的时候,二叉查找树退化为近似链表了,这样的二叉查找树的查找时间复杂度顿时由O(logn)变成了 O(n)

 

mysql二维查询 mysql二叉树查询_平衡树_03

 

平衡二叉树(AVL二叉树):

平衡二叉树就是为了解决二叉查找树退化成一颗链表而诞生了,平衡树具有如下特点

1.具有二叉查找树的全部特性。

2.每个节点的左子树和右子树的高度差至多等于1,超过就会进行自旋进行平衡。

平衡树解决了二叉查找树退化为近似链表的缺点,能够把查找时间控制在 O(logn),不过却不是最佳的,因为平衡树要求每个节点的左子树和右子树的高度差至多等于1,这个要求实在是太严了,导致每次进行插入/删除节点的时候,几乎都会破坏平衡树的第二个规则,进而我们都需要通过左旋和右旋来进行调整,使之再次成为一颗符合要求的平衡树。

显然,如果在那种插入、删除很频繁的场景中,平衡树需要频繁着进行调整,这会使平衡树的性能大打折扣,为了解决这个问题,于是有了红黑树

mysql二维查询 mysql二叉树查询_平衡树_04

 

红黑树:

红黑树属于平衡二叉树的一种。

为什么mysql索引不使用红黑树,是因为在大数据量下,查找也是相当耗时间的。

mysql二维查询 mysql二叉树查询_主键_05

 

Hash表:

索引的数据结构也可以使用Hash表来实现,根据索引字段的值,比如下面图中查找col1=6的数据,是根据Hash(6)算法来得到这行数据的散列值(可以认为是这行数据再磁盘上的地址),再从磁盘中取到数据,但是如果是范围查找,比如查找col1>6的数据,对于这种范围查找,Hash表实现的索引就不太适合了。

mysql二维查询 mysql二叉树查询_mysql二维查询_06

 

tip:

  • 平衡树(AVL)是为了解决 二叉查找树(BST)退化为链表的情况。
  • 红黑树(RBT)是为了解决 平衡树 在删除等操作需要频繁调整的情况

2.B-Tree(B树)

B树叶子节点没有使用指针连接,所以对于范围查找,也不合适。

mysql二维查询 mysql二叉树查询_mysql二维查询_07

3.B+树

mysql索引数据类型默认使用B+树。

B-Tree(B树)和B+Tree(B+树)的区别:

B树的叶子节点没有使用指针连接,B+树使用双指针连接前后节点。

 

mysql二维查询 mysql二叉树查询_mysql二维查询_08

 

4.mysql存储引擎

myisam和innodb存储引擎是形容表的,每张表使用的存储引擎是可以不同的。

mysql二维查询 mysql二叉树查询_主键_09

 

mysql二维查询 mysql二叉树查询_查找树_10

 

5.为什么InnoDB表必须有主键,并且推荐使用整型的自增主键?

第一原因:如果使用UUID这种不是自增,也不是整型的主键,查找的时候根据索引字段的值从索引树中一层层比较去查找到最终的数据,参考下面的图,根据整型主键查找要比UUID这种字符串主键查找时,比较的时候要快。

第二原因:UUID占用字节大于整型字节,消耗存储资源。

mysql二维查询 mysql二叉树查询_查找树_11

 

至于为什么推荐自增呢?

是因为叶子节点(最下面一行的节点),每个叶子节点的存储数量是有限的,如果使用的是自增主键,每次插入新数据的时候,都是再叶子节点的尾部进行插入。

如果使用的是UUID这种无规律的主键,新数据插入的时候,可能要插入到前面叶子节点,比如上图的20-30中间,如果此时图中20-30这个节点已经存储到了16kb(一页16k),那么就要将这个节点分裂,再进行插入,最后再将树做一次平衡。如果这样的情况,不如自增主键,每次都是尾插入,树的平衡相对稳定。

未完,待更新...