MySQL数据结构选择的合理性

MySQL数据结构选择的合理性

从MySQL的角度讲，不得不考虑一个现实的问题的就是磁盘IO。如果我们能够让索引的数据结构尽量减少磁盘I/O操作，所消耗的时间也就越小。可以说，磁盘的I/O操作次数对索引的使用效率至关重要。

查找都是索引操作，一般来说索引非常大，尤其是关系型数据库，当数据量比较大时，索引的大小可能几个G甚至更多，为了减少索引在内存的占用，**数据库索引是存储在外部磁盘上的。**我们利用索引查询的时候，不可能把整个索引加载到内存，只能逐一加载，那么MySQL衡量查询效率的标准就是磁盘的I/O次数。

全表扫描

这里省略。就是索引顺序查找。

Hash结构

Hash本身是一个函数，又被称为散列函数，它可以帮助我们大幅度提升检索的效率。

Hash算法是通过某种确定性的算法（MD5、SHA1、SHA2、SHA3）将输入转变成输出。相同的输入永远可以得到相同的输出，假设输入内容有微小偏差，在输出中通常会有不同的结果。

举例：如果你想要验证两个文件是否相同，那么你不需要把两份文件直接拿来比对，只需要让对方把 Hash函数计算得到的结果告诉你即可，然后在本地同样对文件进行Hash 函数的运算，最后通过比较这两个Hash 函数的结果是否相同，就可以知道这两个文件是否相同。

加速查找的数据结构，常见的有两类“

（1）树，例如平衡二叉搜索树，查询/插入/修改/删除的平均时间复杂度都是O(log2N)；

（2）哈希，例如HashMap，查询/插入/修改/删除的平均时间复杂度是O(1);（key，value）

采用Hash进行检索效率非常高，基本上一次检索就可以找到数据，而B+树需要自顶向下依次查找，多次访问节点才能查找到数据，中间需要多次I/O操作，从效率上来说Hash 比 B树更快。

在哈希的方式下，一个元素K处于H(K)中，即利用哈希函数H，根据关键字K计算出槽的位置。函数H将关键字映射到哈希表T[0…m-1]的槽位上。

上图的哈希函数H可能有两个不同的关键字映射到相同的位置，这叫碰撞，在数据库中一般采用链接法来解决。在链接法中，将散列到同一槽位的元素放在一个链表中，如下图所示：（回忆jdk8中HashMap的底层结构）

全表扫描：

    // 时间复杂度O(log2n)
    @Test
    public void test1() {
   
        int[] arr = new int[100000];
        for (int i = 0; i < arr.length; i++) {
   
            arr[i] = i + 1;
        }
        long start = System.currentTimeMillis();
        for (int i = 1; i < 100000; i++) {
   
            int temp = i;

            for