MySQL批量导入数据时,为何表空间膨胀了N倍

浏览:
字体:
发布时间:2023-01-09 16:12:07
来源:GreatSQL社区

问题缘起

同事在客户现场利用DTS工具,从A实例将数据迁移到B实例过程中,发现几乎稍大点的表在迁移完成后,目标端表空间大小差不多都是源端的3倍,也就是说表空间膨胀了2倍。

排查思路

对这篇文章 《叶问》第16期 有印象的话,应该还能记得,数据迁移(导入导出)过程中,也包括主从复制场景,导致表空间膨胀的原因有几种:

  • MySQL表默认是InnoDB引擎且目前索引只支持B+树索引,在数据的增删改过程中,会因为page分裂而导致表产生碎片,主从服务器上同张表的碎片率不同也会导致表空间相差很大。
  • 主库整理过碎片(相当于重建整表),从库则是从原先的未整理的物理备份中恢复出来的。
  • 两端表结构不一致,如从库可能比主库多索引。
  • 两端表的行格式不一致,如主库为dynamic,从库为compressed。
  • 两端字符集不同,例如源端是latin1,目标端是utf8mb4。
  • 个别云数据库在从库上可能采用特殊的并行复制技术,导致在从库上有更高的碎片率(有个极端的案例,同一个表在主库只有6G,从库上则有将近150G)。
  • 数据表上没有自增ID作为主键,数据写入随机离散,page频繁分裂造成碎片率很高。

问题发现

顺着上面的思路,逐一排查,看能否定位问题原因。

  • 因素1,不存在,这是全量迁移场景,不是在日常随机增删改的过程中导致膨胀的。
  • 因素2,不存在,这是利用DTS工具迁移数据的场景。
  • 因素3、4、5,不存在,两边表结构一致。
  • 因素6,不存在,原因同2。
  • 因素7,不存在,每个表都有自增ID作为主键。

排查到这里,就显得有点诡异了,似乎遇到了玄学问题。不过没关系,我们还需要先了解DTS工具的工作方式,大致如下:

  • 计算数据表总行数。
  • 根据batch size,分成多段并行读取数据;例如总共10000行数据,batch size是1000,则总共分为10次读取数据。
  • 将读取出来的数据拼接成INSERT...VALUES...ON DUPLICATE KEY UPDATE
>更多相关文章
24小时热门资讯
24小时回复排行
资讯 | QQ | 安全 | 编程 | 数据库 | 系统 | 网络 | 考试 | 站长 | 关于东联 | 安全雇佣 | 搞笑视频大全 | 微信学院 | 视频课程 |
关于我们 | 联系我们 | 广告服务 | 免责申明 | 作品发布 | 网站地图 | 官方微博 | 技术培训
Copyright © 2007 - 2024 Vm888.Com. All Rights Reserved
粤公网安备 44060402001498号 粤ICP备19097316号 请遵循相关法律法规
');})();