MySQL索引深入剖析-索引存储模型推演

港控/mmm° 2022-11-04 11:13 144阅读 0赞

## 二分查找 ##

双十一过去之后，你女朋友跟你玩了一个猜数字的游戏。  
猜猜我昨天买了多少钱，给你五次机会。  
10000？低了。30000？高了。接下来你会猜多少？  
20000。为什么你不猜 11000，也不猜 29000 呢？

其实这个就是二分查找的一种思想，也叫折半查找，每一次，我们都把候选数据缩小了一半。如果数据已经排过序的话，这种方式效率比较高。  
所以第一个，我们可以考虑用有序数组作为索引的数据结构。

有序数组的等值查询和比较查询效率非常高，但是更新数据的时候会出现一个问题，可能要挪动大量的数据（改变 index），所以只适合存储静态的数据。

为了支持频繁的修改，比如插入数据，我们需要采用链表。链表的话，如果是单链表，它的查找效率还是不够高。

所以，有没有可以使用二分查找的链表呢？  
为了解决这个问题，BST（Binary Search Tree）也就是我们所说的二叉查找树诞生了。

## 二叉查找树（BST Binary Search Tree） ##

二叉查找树的特点是什么？

**左子树所有的节点都小于父节点，右子树所有的节点都大于父节点**。投影到平面以后，就是一个有序的线性表 。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center]  
二叉查找树既能够实现快速查找，又能够实现快速插入 。

但是二叉查找树有一个问题：

**就是它的查找耗时是和这棵树的深度相关的，在最坏的情况下时间复杂度会退化成O(n)**。

什么情况是最坏的情况呢？

下面这个网站来看一下，这里面有各种各样的数据结构的动态演示，包括BST 二叉查找树：

https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

还是刚才的这一批数字，如果我们插入的数据刚好是有序的，2、6、11、13、17、22。

这个时候我们的二叉查找树变成了什么样了呢？

它会变成链表（我们把这种树叫做“斜树”），这种情况下不能达到加快检索速度的目的，和顺序查找效率是没有区别的。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 1]  
造成它倾斜的原因是什么呢？

因为左右子树深度差太大，这棵树的左子树根本没有节点——也就是它不够平衡。

所以，我们有没有左右子树深度相差不是那么大，更加平衡的树呢？  
这个就是平衡二叉树，叫做 Balanced binary search trees，或者 AVL 树（AVL 是  
发明这个数据结构的人的名字）。

## 平衡二叉树（AVL Tree） （左旋、 右旋） ##

AVL Trees (Balanced binary search trees)

平衡二叉树的定义：左右子树深度差绝对值不能超过 1

是什么意思呢？比如左子树的深度是 2，右子树的深度只能是 1 或者 3。

这个时候我们再按顺序插入 1、2、3、4、5、6，一定是这样，不会变成一棵“斜树”。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 2]  
那它的平衡是怎么做到的呢？怎么保证左右子树的深度差不能超过 1 呢？

https://www.cs.usfca.edu/~galles/visualization/AVLtree.html

插入 1、2、3。  
我们注意看：当我们插入了 1、2 之后，如果按照二叉查找树的定义，3 肯定是要在2 的右边的，这个时候根节点 1 的右节点深度会变成 2，但是左节点的深度是 0，因为它没有子节点，所以就会违反平衡二叉树的定义。

那应该怎么办呢？因为它是右节点下面接一个右节点，右-右型，所以这个时候我们要把 2 提上去，这个操作叫做左旋  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 3]  
同样的，如果我们插入 7、6、5，这个时候会变成左左型，就会发生右旋操作，把 6提上去。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 4]  
所以为了保持平衡，AVL 树在插入和更新数据的时候执行了一系列的计算和调整的操作。

平衡的问题我们解决了，那么平衡二叉树作为索引怎么查询数据？  
在平衡二叉树中，一个节点，它的大小是一个固定的单位，作为索引应该存储什么内容？

它应该存储三块的内容：

第一个是索引的键值。比如我们在 id 上面创建了一个索引，我在用 where id =1 的条件查询的时候就会找到索引里面的 id 的这个键值。

第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。

第三个，因为是二叉树，它必须还要有左子节点和右子节点的引用，这样我们才能找到下一个节点。比如大于 26 的时候，走右边，到下一个树的节点，继续判断。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 5]  
如果是这样存储数据的话，我们来看一下会有什么问题?

在分析用 AVL 树存储索引数据之前，我们先来学习一下 InnoDB 的逻辑存储结构

### InnoDB 逻辑存储结构 ###

https://dev.mysql.com/doc/refman/5.7/en/innodb-disk-management.html  
https://dev.mysql.com/doc/refman/5.7/en/innodb-file-space.html

MySQL 的存储结构分为 5 级：表空间、段、簇、页、行

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 6]

#### 表空间 Table Space ####

表空间可以看做是 InnoDB 存储引擎逻辑结构的最高层，所有的数据都存放在表空间中。分为：系统表空间、独占表空间、通用表空间、临时表空间、Undo 表空间 .

#### 段 Segment ####

表空间是由各个段组成的，常见的段有数据段、索引段、回滚段等，段是一个逻辑的概念。一个 ibd 文件（独立表空间文件）里面会由很多个段组成。

创建一个索引会创建两个段，一个是索引段：leaf node segment，一个是数据段：non-leaf node segment。索引段管理非叶子节点的数据。数据段管理叶子节点的数据。也就是说，一个表的段数，就是索引的个数乘以 2。

#### 簇 Extent ####

一个段（Segment）又由很多的簇（也可以叫区）组成，每个区的大小是 1MB（64个连续的页）。

每一个段至少会有一个簇，一个段所管理的空间大小是无限的，可以一直扩展下去，但是扩展的最小单位就是簇。

#### 页 Page ####

为了高效管理物理空间，对簇进一步细分，就得到了页。簇是由连续的页（Page）组成的空间，一个簇中有 64 个连续的页。 （1MB／16KB=64）。这些页面在物理上和逻辑上都是连续的。

跟大多数数据库一样，InnoDB 也有页的概念（也可以称为块），每个页默认 16KB。页是 InnoDB 存储引擎磁盘管理的最小单位，通过 innodb\_page\_size 设置 .

一个表空间最多拥有 2^32 个页，默认情况下一个页的大小为 16KB，也就是说一个表空间最多存储 64TB 的数据。

注意，文件系统中，也有页的概念。  
操作系统和内存打交道，最小的单位是页 Page。文件系统的内存页通常是 4K。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 7]

SHOW VARIABLES LIKE 'innodb_page_size';

假设一行数据大小是 1K，那么一个数据页可以放 16 行这样的数据。

举例：一个页放 3 行数据。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 8]  
往表中插入数据时，如果一个页面已经写完，产生一个新的叶页面。如果一个簇的所有的页面都被用完，会从当前页面所在段新分配一个簇。

如果数据不是连续的，往已经写满的页中插入数据，会导致叶页面分裂：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 10]

#### 行 Row ####

InnoDB 存储引擎是面向行的（row-oriented），也就是说数据的存放按行进行存放。

https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html

Antelope\[ˈæntɪləʊp\]（羚羊）是 InnoDB 内置的文件格式，有两种行格式：

REDUNDANT\[rɪˈdʌndənt\] Row Format

**COMPACT** Row Format（5.6 默认）

Barracuda\[ˌbærəˈkjuːdə\]（梭子鱼）是 InnoDB Plugin 支持的文件格式，新增了两种行格式：

**DYNAMIC** Row Format（5.7 默认）

COMPRESSED Row Format

<table> 
 <thead> 
  <tr> 
   <th>文件格式</th> 
   <th>行格式</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Antelope （Innodb-base）</td> 
   <td>ROW_FORMAT=COMPACT<br>ROW_FORMAT=REDUNDANT</td> 
   <td>Compact 和 redumdant 的区别在就是在于首部的存 存内容区别。<br>compact 的存储格式为首部为一个非 NULL 的变长字 段长度列表<br>redundant 的存储格式为首部是一个字段长度偏移 列表（每个字段占用的字节长度及其相应的位移） 。<br>在 Antelope 中对于变长字段， 低于 768 字节的， 不 会进行 overflow page 存储， 某些情况下会减少结果 集 IO.</td> 
  </tr> 
  <tr> 
   <td>Barracuda (innodb-plugin)</td> 
   <td>ROW_FORMAT=DYNAMIC<br>ROW_FORMAT=COMPRESSED</td> 
   <td>这两者主要是功能上的区别功能上的。 另外在行 里的变长字段和 Antelope 的区别是只存 20 个字节， 其它的 overflow page 存储。<br>另外这两都需要开启 innodb_file_per_table=1</td> 
  </tr> 
 </tbody> 
</table>

innodb\_file\_format 在配置文件中指定；row\_format 则在创建数据表时指定。

show variables like "%innodb_file_format%";
    SET GLOBAL innodb_file_format=Barracuda;

![在这里插入图片描述][2021030210000943.png_pic_center]  
在创建表的时候可以指定行格式

CREATE TABLE tf1
    (c1 INT PRIMARY KEY)
    ROW_FORMAT=COMPRESSED
    KEY_BLOCK_SIZE=8;

查看行格式：

SHOW TABLE STATUS LIKE 'student' \G;

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 11]  
以上内容就是了解页 page 的概念

### AVL 树用于存储索引数据 ###

首先，索引的数据，是放在硬盘上的。查看数据和索引的大小：

SELECT
    CONCAT(ROUND(SUM(DATA_LENGTH/1024/1024),2),'MB') AS data_len ,
    CONCAT(ROUND(SUM(INDEX_LENGTH/1024/1024),2),'MB') AS index_len
    FROM information_schema.TABLES
    WHERE table_schema='idaas' AND table_name='id_t_user_base';

当我们用树的结构来存储索引的时候，访问一个节点就要跟磁盘之间发生一次 IO。  
InnoDB 操作磁盘的最小的单位是一页（或者叫一个磁盘块），大小是 16K(16384 字节)。

那么，一个树的节点就是 16K 的大小

如果我们一个节点只存一个键值+数据+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远远达不到 16K 的容量，所以访问一个树节点，进行一次 IO 的时候， 浪费了大量的空间。

所以如果每个节点存储的数据太少，从索引中找到我们需要的数据，就要访问更多的节点，意味着跟磁盘交互次数就会过多 .

如果是机械硬盘时代，每次从磁盘读取数据需要 10ms 左右的寻址时间，交互次数越多，消耗的时间就越多。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 12]  
比如上面这张图，我们一张表里面有 6 条数据，当我们查询 id=37 的时候，要查询 两个子节点，就需要跟磁盘交互 3 次，如果我们有几百万的数据呢？这个时间更加难以估计。

所以我们的解决方案是什么呢？

第一个就是让每个节点存储更多的数据

第二个，节点上的关键字的数量越多，我们的指针数也越多，也就是意味着可以有更多的分叉（我们把它叫做“路数”）。

因为分叉数越多，树的深度就会减少（根节点是 0）。

这样，我们的树是不是从原来的高瘦高瘦的样子，变成了矮胖矮胖的样子？

这个时候，我们的树就不再是二叉了，而是多叉，或者叫做多路。

## 多路平衡查找树（B Tree） （分裂、 合并） ##

Balanced Tree

这个就是我们的多路平衡查找树，叫做 B Tree（B 代表平衡）

跟 AVL 树一样，B 树在枝节点和叶子节点存储键值、数据地址、节点引用。  
它有一个特点：**分叉数（路数）永远比关键字数多 1**。比如我们画的这棵树，每个节点存储两个关键字，那么就会有三个指针指向三个子节点。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 13]  
B Tree 的查找规则是什么样的呢？  
比如我们要在这张表里面查找 15。  
因为 15 小于 17，走左边。  
因为 15 大于 12，走右边。  
在磁盘块 7 里面就找到了 15，只用了 3 次 IO。

这个是不是比 AVL 树效率更高呢？

那 B Tree 又是怎么实现一个节点存储多个关键字，还保持平衡的呢？跟 AVL 树有什么区别？

https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

比如 Max Degree（路数）是 3 的时候，我们插入数据 1、2、3，在插入 3 的时候，本来应该在第一个磁盘块，但是如果一个节点有三个关键字的时候，意味着有 4 个指针，子节点会变成 4 路，所以这个时候必须进行分裂。把中间的数据 2 提上去，把 1 和 3 变成 2 的子节点。

如果删除节点，会有相反的合并的操作。

注意这里是分裂和合并，跟 AVL 树的左旋和右旋是不一样的。  
我们继续插入 4 和 5，B Tree 又会出现分裂和合并的操作。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 14]  
从这个里面我们也能看到，在更新索引的时候会有大量的索引的结构的调整，所以解释了为什么我们不要在频繁更新的列上建索引，或者为什么不要更新主键。

节点的分裂和合并，其实就是 InnoDB 页的分裂和合并。

## B+树（加强版多路平衡查找树） ##

B Tree 的效率已经很高了，为什么 MySQL 还要对 B Tree 进行改良，最终使用了B+Tree 呢？

总体上来说，这个 B 树的改良版本解决的问题比 B Tree 更全面。  
我们来看一下 InnoDB 里面的 B+树的存储结构：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 15]  
**MySQL 中的 B+Tree 有几个特点：**

1、它的关键字的数量是跟路数相等的；

2、\*\*B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索 id=28，虽然在第一层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点 \*\*。

举个例子：假设一条记录是 1K，一个叶子节点（一页）可以存储 16 条记录。非叶子节点可以存储多少个指针？

假设索引字段是 bigint 类型，长度为 8 字节。指针大小在 InnoDB 源码中设置为6 字节，这样一共 14 字节。非叶子节点（一页）可以存储 16384/14=1170 个这样的单元（键值+指针），代表有 1170 个指针。

树 深 度 为 2 的 时 候 ， 有 1170^2 个 叶 子 节 点 ， 可 以 存 储 的 数 据 为1170*1170*16=21902400。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 16]  
在查找数据时一次页的查找代表一次 IO，也就是说，一张 2000 万左右的表，查询数据最多需要访问 3 次磁盘。

所以在 InnoDB 中 B+ 树深度一般为 1-3 层，它就能满足千万级的数据存储。

3、B+Tree 的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。

4、它是根据左闭右开的区间 \[ )来检索数据

来看一下 B+Tree 的数据搜寻过程：

1）比如我们要查找 28，在根节点就找到了键值，但是因为它不是页子节点，所以会继续往下搜寻，28 是\[28,66)的左闭右开的区间的临界值，所以会走中间的子节点，然后继续搜索，它又是\[28,34)的左闭右开的区间的临界值，所以会走左边的子节点，最后在叶子节点上找到了需要的数据。

2）第二个，如果是范围查询，比如要查询从 22 到 60 的数据，当找到 22 之后，只要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高 了区间查询效率（不需要返回上层父节点重复遍历查找）。

**总结一下，InnoDB 中的 B+Tree 的特点：**

1.  它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。B Tree 解决的两大问题是什么？（每个节点存储更多关键字；路数更多）

2)扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵 B+Tree 拿到所有的数据）

1.  B+Tree 的磁盘读写能力相对于 B Tree 来说更强（根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多）

4)排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链表）

5)效率更加稳定（B+Tree 永远是在叶子节点拿到数据，所以 IO 次数是稳定的）

## 索引方式： 真的是用的 B+Tree 吗 ##

在 Navicat 的工具中，创建索引，索引方式有两种，Hash 和 B Tree。  
HASH：以 KV 的形式检索数据，也就是说，它会根据索引字段生成哈希码和指针，指针指向数据。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 17]  
哈希索引有什么特点呢？

第一个，它的时间复杂度是 O(1)，查询速度比较快。**因为哈希索引里面的数据不是按顺序存储的，所以不能用于排序。**

第二个，我们在查询数据的时候要根据键值计算哈希码，所以它只能支持等值查询（= IN），不支持范围查询（> < >= <= between and）

另外一个就是如果字段重复值很多的时候，会出现大量的哈希冲突（采用拉链法解决），效率会降低。

问题： InnoDB 可以在客户端创建一个索引，使用哈希索引吗？

https://dev.mysql.com/doc/refman/5.7/en/innodb-introduction.html  
InnoDB utilizes hash indexes internally for its Adaptive Hash Index feature

直接翻译过来就是：InnoDB 内部使用哈希索引来实现自适应哈希索引特性 。

这句话的意思是\*\* InnoDB 只支持显式创建 B+Tree 索引\*\*，对于一些热点数据页，InnoDB 会自动建立自适应 Hash 索引，也就是在 B+Tree 索引基础上建立 Hash 索引，这个过程对于客户端是不可控制的，隐式的 。

**我们在 Navicat 工具里面选择索引方法是哈希，但是它创建的还是 B+Tree 索引，这个不是我们可以手动控制的。**

buffer pool 里面有一块区域是 Adaptive Hash Index 自适应哈希索引，就是这个

这个开关默认是 ON :

show variables like 'innodb_adaptive_hash_index';

从存储引擎的运行信息中可以看到：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 18]  
因为B Tree 和B+Tree 的特性，它们广泛地用在文件系统和数据库中，例如Windows的 HPFS 文件系统，Oracel、MySQL、SQLServer 数据库。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221023/ee999f8862ed4e2b9794a044ec339e92.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221023/d45941a52de9405a8133b78c2b057fbf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221023/19c3a94e44e74c48b856077758656939.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221023/894504758fda47d8bb9bf747c3368157.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221023/95d527cdfe1a4772bc55d1f8ba71974a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221023/1f0ebdde44544744a6420c6a7888fc73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221023/3ac8476b13a64f8882feeb1b725d9e77.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221023/614c5b2fc7504b0081abc81ac73e0c42.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221023/71d280a14892495f88b1970a16a1ef9c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221023/972fd35f667b41889d3ba81aabfc7bb3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221023/fcf0695d55d146eab96452f4e2aa553d.png
[2021030210000943.png_pic_center]: /images/20221023/a6a46469ca2b4f4a99f147a08889292d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221023/62de250ead0d4b43be9f9ec6323ab888.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221023/9b12d63e4a564e7db82a11a84206e472.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 13]: /images/20221023/3a010bd61d1d4857a231653dd637b402.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 14]: /images/20221023/8d5f36ee8e8b4efa934d702eb33b93cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 15]: /images/20221023/7e15d34b03864f62a1d320f7f27cc59f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 16]: /images/20221023/93ea7ea3823c4dedadccdc2a66f433e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 17]: /images/20221023/0bc9ee7cc7cc404986fbdd020e3ed7f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70_pic_center 18]: /images/20221023/0eef0b6f5082499c854b8252f3283103.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70]: /images/20221023/2db7639588c44969a297b0d361a6d9ff.png

MySQL索引深入剖析-索引存储模型推演

发表评论取消回复

还没有评论，来说两句吧...

相关阅读