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

问题缘起

同事在客户现场利用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