数据库索引和磁盘的关系大揭秘

一、序言

都说加索引能加快查询的速率，着实通过索引本质上是淘汰磁盘的读取次数，到底索引和磁盘的关系是怎样的呢？

---

二、磁盘布局

起首我们先相识一下利用体系是怎么从磁盘中读取数据的，利用体系通常是以页为单元从磁盘中读取数据，磁盘可以明白为一个圆盘，每个圆盘上有多少磁道。
比如下面的图有4种差异颜色的磁道，每条磁道上每个半圆代表一个扇区，也就是一条磁道在这里被分别为4个扇区。

利用体系从磁盘中读取数据时，也是按页(扇区)来读取，读取一块数据，我们称之为1个block块。
差异硬盘每个扇区的存储容量不一样。

• 呆板硬盘：每个扇区为512B。
  
• 固态硬盘(SSD)：page巨细为4KB。
  

   备注：为什么要以页为单元从磁盘读取数据呢？
如果每次只查询1条记录，由于磁盘检索速率比力慢，会有肯定的性能斲丧。但如果每次读一页数据，会淘汰磁盘读取的次数。
  

---

三、磁盘中数据存储

假设有一张用户表，表中共有效户ID、用户名、暗码、头像、备注5个字段，字段长度如下：

根据字段长度界说，一条记录的巨细为128字节，而呆板硬盘一个扇区最多能存储512字节，也就说是一次扇区扫描最多能读取4条记录。
我们把从磁盘扇区读取的数据称之为1个block，

• 一个block可以存储512 / 128 = 4条记录
  
• 100条记录则必要100 / 4 = 25个block
  

也就是说读取user_id为100的记录最多必要访问25个block，也就是25次磁盘问询。
如果说要读取user_id为1000的记录，则最多必要举行250次的磁盘问询，如果数据量更大呢？这个时间索引的作用就出来了。
四、索引在磁盘中的存储

上面的例子中，数据量越大，磁盘问询的的次数也就越多，我们可以做一个优化，对user_id列加上索引。

上面我们说了假设该用户表1条记录占128字节，1个block可以存放512 / 128 = 4条记录。
如今对user_id列加上索引，该索引会生存该列的数据和数据指针(指向数据所在的磁盘扇区)。
假设数据指针为6字节，那么一条索引将占用该列长度10 + 6 = 16字节，1个block(512字节)可以存放512 / 16 = 32条索引记录。100条索引记录必要占用100 / 32 = 4个block。
上面说了100条数据记录必要占用100 / 4 = 25个block。以这100条数据为例，我们用4个block存索引数据，25个block存储列数据。
这个时间读取user_id为100个记录，我们先扫描索引，最多读取4个block就可以找到该数据所在磁盘扇区，再颠末1次磁盘问询就可以找到该数据，也就是说最多颠末5次磁盘问询。
如果是读取user_id为1000的记录，最多读取32个block索引数据加上1个block列数据，也就是33次磁盘问询就能找到。
而且内存访问比磁盘快，由于索引数据比力小，我们完全可以将索引数据加载到内存，如许访问会更快。
   备注：InnoDB中索引数据和列数据在同一个(.ibd)文件，而索引数据总是在文件的最前面，查询数据时先扫描索引。
  

---

五、二级索引

题目又来了，如果数据量越来越大，酿成10w条，100w条，就算创建10w条，100w条索引，速率还是会越来越慢，该怎么办呢？
我们可以针对索引再见索引，什么意思呢？

上面说了，1000条数据必要构建32个索引block，如果我们以32为单元，只存32条二级索引记录，再次构建二级索引，则只必要1个索引block。（二级索引只存放user_id值为32及其倍数的数据）
以这1000条数据为例，我们用1个block存二级索引数据，32个block存1级索引数据，250个block存列数据。
这个时间如果读取user_id为1000的记录，只必要读取1个二级索引block，1个一级索引块，再颠末1次磁盘问询就能找到，也就是最多3次磁盘问询。
固然，随着数据量越来越大，二级索引数据也会越来越大，为了更好明白，我们将它转换为树的情势，是不是以为很认识。

固然实际索引数据布局，像B+树等多路平衡树会更加复杂，这个我们反面再分享。