InnoDB数据页什么时候合并(1)

简介: InnoDB数据页什么时候合并

1. 为什么要合并数据页


我们知道,当从InnoDB表删除数据时,相应的数据是先打上删除标签(deleted mark),而后再由purge线程执行清理工作。

清理工作结束后,如果两个相邻的数据页存储填充率低于一定程度,就会尝试合并页,以降低碎片率,提高存储效率。

或者经过多次长度变小的UPDATE操作后(将varchar列长度更新变短),数据页填充率低于一定程度也会尝试合并。

合并完毕之后,空出来的页就会被标记为空闲页,等待再分配。

这个工作是InnoDB后台线程自动完成的,无需人为干预、控制。


2. 什么时候合并数据页


MySQL官方手册 The InnoDB Storage Engine / InnoDB Configuration / Configuring the Merge Threshold for Index Pages 中其实已经详细说明了什么时候会进行合并。

通过调整参数 MERGE_THRESHOLD 的值,当InnoDB数据页填充率低于该阈值时,就会尝试进行合并页操作。

该参数默认值是 50,最小值是 1,在5.6版本之后允许自行指定设置,在5.6之前的版本中则是被硬编码的,无法修改。



When the “page-full” percentage for an index page falls below 50%, which is the default MERGE_THRESHOLD setting, InnoDB attempts to merge the index page with a neighboring page. If both pages are close to 50% full, a page split can occur soon after the pages are merged.

简言之,就是当发现两个相邻页的填充率都低于50%时,就会尝试进行合并。


2.1 准备测试环境

我们拿一个实际案例进行测试,观察InnoDB的页合并是怎么做的。

测试表DDL

CREATE TABLE `t_sk` (

`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`c1` int(10) unsigned NOT NULL DEFAULT '0',
`c2` int(10) unsigned NOT NULL,
`c3` int(10) unsigned NOT NULL,
`c4` int(10) unsigned NOT NULL,
`c5` datetime NOT NULL,
`c6` char(20) NOT NULL,
`c7` varchar(30) NOT NULL,
`c8` varchar(30) NOT NULL,
`c9` varchar(30) NOT NULL,
PRIMARY KEY (`id`),
KEY `k1` (`c1`)
) ENGINE=InnoDB COMMENT='MERGE_THRESHOLD=30';



特地设置了 MERGE_THRESHOLD=30,看看page的填充率在高于30%时会不会发生合并。

mysql_random_data_load 灌入一些测试数据。

本文使用的MySQL版本是Percona-Server-5.7.22,下载源码后自编译的。

Server version:        5.7.22-22-log Source distribution



2.2 找到两个相邻页

随机找到其中的两个相邻的页,pageno分别是7和8。

innodb_ruby 工具扫描这两个page中的数据:

[root@yejr.run]# innodb_space -s ibdata1 -T test/t_sk -p 7 page-records > recs-no7.txt

[root@yejr.run]# cat recs-no7.txt
Record 128: (id=252)...
...
Record 15143: (id=351)...

非常巧,这个page中共有100条记录,其ID值从 252 ~ 351。

同样地,扫描8号page,也正好有100条记录,其ID值从 352 ~ 451。


2.3 试探性逐步删除数据,接近阈值

先利用 innodb_ruby 工具查看page-dump的结果:

[root@yejr.run]# innodb_space -s ibdata1 -T test/t_sk -p 7 page-dump > dump-no7.txt
...
sizes:
header 120
trailer 8
directory 52
free 1054
used 15330
record 15150
per record 151.00
...

从上面信息可以看到,每条记录平均长度是151字节,共100条记录。

如果想让填充率低于30%,那么需要删除的数据量大概是:

ceil((15150 - 16384  0.3) / 151) = 68

关于上述公式简要说明下:

  • 当前的数据所占字节数是:15150
  • 只剩30%填充率的字节数是:16384 0.3
  • 每条记录平均长度字节数是:151
    这样应该能看懂吧。
    也就是两个page分别都需要删除68条记录才会触发合并操作。

好了,针对上述两个ID值区间,先各自分别删除67条数据,只差一条数据就达到临界点,看看后续会不会发生合并。

[root@yejr.run]> delete from t_sk where id>=252 and id <= 318;
Query OK, 67 rows affected (0.01 sec)

[root@yejr.run]> delete from t_sk where id>=352 and id <= 418;
Query OK, 67 rows affected (0.00 sec)



先用 innblock 工具快速扫描:

[root@yejr.run]# innblock test/t_sk.ibd 7 16 | grep n_rows; innblock test/t_sk.ibd 8 16 | grep n_rows
slot_nums:9 heaps_rows:102 n_rows:33
slot_nums:9 heaps_rows:102 n_rows:33



确认两个page还没合并,各自都只剩33条记录。

再看两个page的填充率情况:

#扫描pageno=7
[root@yejr.run]# innodb_space -s ibdata1 -T test/t_sk -p 7 page-dump
...
sizes:
header 120
trailer 8
directory 18
free 11198
used 5186
record 5040
per record 152.00
...

#扫描pageno=8
[root@yejr.run]# innodb_space -s ibdata1 -T test/t_sk -p 8 page-dump
...
sizes:
header 120
trailer 8
directory 18
free 11200
used 5184
record 5038
per record 152.00
...



此时两个page的填充率分别是:

5040/16384 = 0.3076171875
5038/16384 = 0.3074951171

都超过了 MERGE_THRESHOLD=30 阈值,所以还没有进行合并。


2.4 再次只删除一条记录,验证是否合并

接下来,我们分别对两个page再各自删除一条记录,使得填充率低于临界点:

[root@yejr.run]> delete from t_sk where id in (319, 419);
Query OK, 2 rows affected (0.01 sec)



还是用 innblock 工具扫描,不过这次先扫描第7号page,看看是不是把8号page合并过来了。

[root@yejr.run]# innblock test/t_sk.ibd 7 16 | grep n_rows; innblock test/t_sk.ibd 8 16 | grep n_rows
slot_nums:16 heaps_rows:67 n_rows:64
slot_nums:9 heaps_rows:102 n_rows:32
...



果真如此,发现第7号page当前有64条记录,这是两个page合并之后的结果。

而第8号page因为已经被合并了,被标记为空闲page,此时已经从索引树里被摘掉了:

[root@yejr.run]# innodb_space -s ibdata1 -T test/t_sk -I PRIMARY -l 0 index-level-summary
page index level data free records min_key
4 54 0 7536 8692 50 id=1
5 54 0 15118 1086 100 id=52
6 54 0 15103 1101 100 id=152
7 54 0 9768 6456 64 id=320
9 54 0 15159 1045 100 id=452
10 54 0 15056 1150 99 id=552


很明显,第8号page已经不在列表中了。只不过page被合并后,里面的物理记录还存着,并没有立即被抹掉,等以后被重用时直接覆盖就好了。

至此,page合并试验结束。


3. 其他补充说明


3.1 除了表级可以设置外,单个索引也可以设置合并阈值

对InnoDB来说,其实整个表都是索引页,无非是聚集索引页还是辅助索引页而已。

因此,页合并阈值既可以用于聚集索引页,也可以用于辅助索引页。

只需要在创建索引时指定即可:

[root@yejr.run]> ALTER TABLE t_sk ADD INDEX k1(c1) COMMENT 'MERGE_THRESHOLD=20';


当然了,这个只能在创建索引时一次性指定,不能中途修改。

然而,表级别的合并阈值则可以在运行时修改:

[root@yejr.run]> ALTER TABLE t_sk COMMENT 'MERGE_THRESHOLD=40';
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0


            </div>
相关文章
|
小程序
小程序踩坑:Setting data field "xxxx" to undefined is invalid.
小程序踩坑:Setting data field "xxxx" to undefined is invalid.
560 0
|
存储 数据库 Android开发
|
1月前
|
机器学习/深度学习 人工智能 自然语言处理
41_涌现能力:从zero-shot到in-context学习
在人工智能领域,2022年以来,大语言模型(LLM)展现出的一系列惊人能力引发了广泛关注。其中最令人着迷的现象之一,就是**涌现能力**(Emergent Abilities)——当模型规模超过某个临界点时,突然表现出的在小模型中不存在的新能力。这种量变引发质变的神奇现象,彻底改变了我们对AI发展路径的认知。从最初只能进行简单文本生成的模型,到如今能够理解复杂指令、执行多步推理、甚至在未经过专门训练的任务上表现出色的AI系统,大语言模型正逐步逼近人类级别的认知能力。
|
4月前
|
持续交付 Windows
如何使用Sysprep准备Windows系统并使用自动应答
通过Sysprep准备Windows系统,可实现SID重置与系统定制。进入Sysprep后,可安装软件、设置默认桌面文件,并使用Windows SIM创建应答文件以实现自动化部署。适用于系统克隆与批量部署场景。
|
9月前
|
存储 弹性计算 安全
阿里云服务器实例选择:经济型、通用算力型、计算型、通用型、内存型实例选择参考
当我们通过阿里云的活动购买云服务器会发现,相同配置的云服务器往往有多个不同的实例可选,而且价格差别也比较大,例如同样是4核8G的配置的云服务器,经济型e实例活动价格1595.11元/1年起,通用算力型u1实例要955.58元/1年起,而计算型c8i实例则要2845.81元/1年起,价格差别还是比较大的,因此,阿里云经济型、通用算力型、计算型、通用型、内存型实例云服务器有何差别就是很多新手用户比较关心的问题了,下面小编来为大家简单介绍下它们之间的区别。
680 16
WK
|
开发框架 移动开发 Java
C++和Java哪个更适合开发移动应用
本文对比了C++和Java在移动应用开发中的优劣,从市场需求、学习难度、开发效率、跨平台性和应用领域等方面进行了详细分析。Java在Android开发中占据优势,而C++则适合对性能要求较高的场景。选择应根据具体需求和个人偏好综合考虑。
WK
371 0
|
JSON 缓存 Java
Spring Boot集成 Swagger2 展现在线接口文档
本节课详细分析了 Swagger 的优点,以及 Spring Boot 如何集成 Swagger2,包括配置,相关注解的讲解,涉及到了实体类和接口类,以及如何使用。最后通过页面测试,体验了 Swagger 的强大之处,基本上是每个项目组中必备的工具之一,所以要掌握该工具的使用,也不难。
|
机器学习/深度学习 计算机视觉
CVPR 2024:字节提出新一代数据集COCONut,比COCO粒度分割更密集
【5月更文挑战第5天】在CVPR 2024会议上,字节跳动推出了COCONut数据集,作为COCO的升级版,用于更密集的图像分割任务。COCONut包含383K张图像和5.18M个分割标注,质量与规模均超越COCO,提供更准确、一致的标注,并有更多类别。其密集标注有助于理解图像细节,但大規模与高标注质量也可能带来训练资源和过拟合的挑战。[链接](https://arxiv.org/abs/2404.08639)
620 2
|
消息中间件 传感器 运维
软件体系结构 - 架构风格(7)事件驱动架构风格
【4月更文挑战第21天】软件体系结构 - 架构风格(7)事件驱动架构风格
740 0