MySQL迁移12GB表生成40GB Binlog 容量远超原始数据问题咨询

一、Binlog容量为原表3倍的核心原因 #

以下是MySQL 5.7环境下最常见的触发场景，按影响概率从高到低排序：

• Binlog行格式+额外日志参数开启
  MySQL 5.7默认使用ROW格式的Binlog，该格式会记录每行变更的完整镜像，本身就比STATEMENT格式占用更多空间。如果节点2开启了binlog_rows_query_log_events参数，还会在Binlog中额外记录对应的原始SQL语句，相当于同一份变更数据存了两份（行镜像+原始SQL），直接导致体积翻倍甚至更高。
  你可以执行SHOW VARIABLES LIKE 'binlog_format';确认当前Binlog格式，执行SHOW VARIABLES LIKE 'binlog_rows_query_log_events';检查是否开启了额外的SQL记录。
• 逻辑迁移的事务/事件开销放大
  如果你使用mysqldump等逻辑迁移工具，且导出时没有开启批量扩展插入、导入时使用了小事务提交，每个INSERT行、每个事务都会产生固定的Binlog事件头开销。当数据量较大时，这类开销的累计占比会非常高，极端情况下可以超过数据本身的体积。
  另外你看到的12GB表容量通常是information_schema.TABLES中统计的data_length + index_length，也就是包含了索引的磁盘占用，而Binlog仅记录行数据变更不记录索引生成逻辑，所以如果你的表索引占比较高，实际需要记录的行数据量占原表容量的比例本身就更低，叠加开销后膨胀倍数会显得更高。
• 在线迁移工具的额外日志写入
  如果你使用gh-ost、pt-online-schema-change这类在线迁移工具，工具会在迁移过程中持续写入心跳事件、元数据标记事件到目标库的Binlog中，迁移大表时这部分额外日志的体积也会非常可观。
• 未开启Binlog压缩
  MySQL 5.7版本原生不支持Binlog压缩（该特性从MySQL 8.0开始引入），所有Binlog内容都是明文存储，没有压缩率的空间节省。

二、NULL列对Binlog容量的影响 #

允许为NULL的列确实会小幅增加Binlog体积，但影响可以忽略：ROW格式的Binlog中会维护一张NULL位图，每个允许为NULL的列固定占用1位的空间，不管该列实际值是不是NULL，都会占对应的位图位。但哪怕表中有上百个允许为NULL的列，每行增加的开销也只有几十字节，不可能导致3倍的体积膨胀，所以你的场景下NULL列不是核心诱因。

内容的提问来源于stack exchange，提问作者user2894829