MariaDB 10.5.15压缩存储数据后磁盘占用增加的原因排查

可能的核心原因 #

1. InnoDB空闲空间未及时复用 #

InnoDB更新字段为NULL时，不会立即释放原字段占用的磁盘空间，只会将其标记为内部可复用的空闲空间。由于你的表主键是自增的（id bigint AUTO_INCREMENT），新插入的记录会优先写入新的页，而非复用这些空闲空间。这就导致旧字段占用的空间没被回收，同时新增的encrypted_file_v2又占用了额外空间，整体磁盘占用暂时上升。只有当后续有大量更新操作需要占用这些空闲空间时，才会被复用，但如果业务以插入为主，这些空间可能长期闲置。

2. 表结构变更与更新操作产生的额外开销 #

• 新增字段时，InnoDB的在线DDL过程可能生成临时表空间，或导致原表产生页碎片。
• 将原字段设为NULL的批量更新操作，会产生大量undo日志和redo日志，这些日志文件会临时占用磁盘空间。虽然InnoDB会定期清理，但如果每日写入量较大，日志的增长幅度可能超过数据文件的缩减幅度。

3. 字段类型的隐性开销 #

压缩后的二进制数据用mediumtext存储不如mediumblob高效：text类型会按字符集（如utf8mb4）处理，可能引入额外的编码开销；而blob是纯二进制存储，更适配压缩后的字节数据。这会导致单条记录的实际磁盘占用比预期偏高。

4. 生产与本地环境的差异 #

• 本地测试数据量小，可能触发了InnoDB的空间回收（如自动清理或手动执行OPTIMIZE TABLE），而生产环境数据量大，空间回收触发条件更严格。
• 生产环境通常开启二进制日志（binlog），更新操作会被完整记录，这部分日志会占用额外磁盘空间；本地测试可能未开启binlog，或日志清理策略更激进。
• 生产环境若使用独立表空间（innodb_file_per_table=ON），释放的空间不会归还操作系统，仅在表内部复用；本地测试可能用共享表空间，或测试后手动清理了空间。

验证与解决步骤 #

• 检查表空闲空间：执行以下命令查看表的未使用空间：

  SHOW TABLE STATUS LIKE 'Persons'\G
  

  关注Data_free字段，若数值较大，说明存在大量未被复用的空闲空间。

• 手动回收空间：在业务低峰期执行（会锁表，需谨慎）：

  OPTIMIZE TABLE Persons;
  

  该命令会重建表并释放未使用的空间。

• 优化字段类型：将encrypted_file_v2改为mediumblob，避免字符编码开销：

  ALTER TABLE Persons MODIFY COLUMN encrypted_file_v2 mediumblob;
  

• 调整日志策略：检查binlog过期时间设置，确保旧日志及时清理：

  SHOW VARIABLES LIKE 'expire_logs_days';
  -- 若过期时间过长，可调整为7天（根据业务需求）
  SET GLOBAL expire_logs_days = 7;
  

• 监控空间变化：跟踪表数据文件（Persons.ibd）、InnoDB日志文件（ib_logfile*）、binlog文件的大小变化，定位空间增长的来源。

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