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
>更多相关文章
- 06-16卡巴斯基郑启良:支持信创发展是卡巴斯基的重要使命
- 06-16访问管理是确保现代工作场所安全的的五个关键原因
- 06-16零信任安全的演变:彻底改变网络安全策略
- 06-16GitHub上值得关注的20个网络安全项目
- 06-16英国曼彻斯特大学遭遇网络攻击,机密数据或遭窃!
- 06-16调查表明广告软件推送恶意软件感染了六万多个安卓应用程序
- 06-16微软向美国政府提供GPT的大模型,安全性如何保证?
- 06-16如何保护OT环境免受安全威胁?
首页推荐
佛山市东联科技有限公司一直秉承“一切以用户价值为依归
- 01-11全球最受赞誉公司揭晓:苹果连续九年第一
- 12-09罗伯特·莫里斯:让黑客真正变黑
- 12-09谁闯入了中国网络?揭秘美国绝密黑客小组TA
- 12-09警示:iOS6 惊现“闪退”BUG
- 10-29同程旅行回应酒店订单“订后即焚” 将考虑是
- 10-29阿里国际站发布全流程AI产品 推进更高效经营
- 10-25亿纬锂能第33工厂首颗圆柱电池下线
- 10-25外媒称苹果正开发 iOS 游戏中心
- 10-25快递业展现强劲发展韧性,单日业务量创历史
相关文章
24小时热门资讯
24小时回复排行
热门推荐
最新资讯
操作系统
黑客防御