面试问到了K8S原理

表中 R1~R5 的 (ID,k) 值分别为 (10,1)、(20,2)、(30,3)、(50,5) 和 (70,7)，索引id和索引k的B+树的示例示意图如下。

根据叶子节点的内容，索引类型分为主键索引和非主键索引，主键索引的叶子节点存的是整行数据R1~R5，非主键索引的叶子节点内容是主键的值。

从图中可以看出，基于非主键索引的查询需要多扫描一棵索引树才能找到对应的数据。提一句题外话，我们在应用中应该尽量使用主键查询。

3.索引维护
B+ 树为了维护索引有序性，在增删改数据的时候需要做必要的维护。

假设，我们要删掉 R4 这个记录，InnoDB 引擎只会把 R4 这个记录标记为删除。如果之后要再插入一个 ID 在 300 和 600 之间的记录时，可能会复用这个位置。

如果删掉了一个数据页上的所有记录，那么整个数据页就能被复用了。进一步地，如果我们用 delete 命令把整个表的数据删除呢？结果就是，这个表相关的所有的数据页都会被标记为可复用。

但是，无论如何，磁盘文件的大小并不会缩小。

这些被标记为可复用，而并没有实际被使用的空间，就是一些“存储空洞”。
 

1.背景
在完成一个分表项目后，发现分表的数据迁移后，新库所需的存储容量远大于原本两张表的大小。在做了一番查询了解后，完成了优化。

回过头来，需要进一步了解下为什么会出现这样的情况。

与标题的问题的类似问题还有，为什么表数据内容删除了而表大小没有变化。其本质都是一样的。

要回答这些问题，我们需要从mysql的索引模型谈起。

2.InnoDB 的索引模型
在 MySQL 中，索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。

而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。由于 InnoDB 存储引擎在 MySQL 数据库中使用最为广泛，所以接下来就以 InnoDB 为例，分析其中的索引模型。

在 InnoDB 中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表。而InnoDB中，使用了 B+ 树索引模型，所以数据都是存储在 B+ 树中的，每一个索引会对应一颗B+树。

假设，我们有一个主键列为 ID 的表，表中有字段 k，并且在 k 上有索引，建表语句如下

• CREATE TABLE `t` (
• `id` int(11) NOT NULL,
• `k` int(11) NOT NULL,
• `name` varchar(16) DEFAULT NULL,
• PRIMARY KEY (`id`),
• KEY `k` (`k`)
• ) ENGINE=InnoDB DEFAULT CHARSET=utf8

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!