H2数据库磁盘占用远超预期达7倍的原因排查求助

首先得说这种情况在H2里挺常见的，毕竟它的存储机制有不少容易被忽略的细节，咱们一步步来拆解排查：

• 数据页的固有开销
  H2是基于页的存储引擎，默认页大小一般是4KB（可通过PAGE_SIZE参数调整）。就算你每行刚好80字节，一页也只能放下4096 / 80 = 51行，28万行就需要大概5490页，光这部分就接近22MB了，但每页还有页头、校验信息、指针这些元数据（大概几十字节/页），这会额外增加一点占用，但如果实际远大于22MB，这肯定不是主要原因。

• MVCC版本数据残留
  H2默认启用MVCC（多版本并发控制），当你更新或删除数据时，旧的数据版本不会立即被物理删除，而是会保留下来供未提交的事务读取。如果这张表之前有过大量的更新、删除操作，或者有长期未提交的事务，这些旧版本数据会一直占着磁盘空间。
  你可以先试试执行压缩命令：

  COMPACT TABLE your_table_name;
  

  如果是整个数据库的问题，也可以在关闭数据库前执行：

  SHUTDOWN COMPACT;
  

  执行后再查看磁盘占用，应该会有明显变化。

• 事务日志与临时文件残留
  H2运行时会生成事务日志（.log后缀）和临时文件（.tmp后缀），如果数据库异常关闭（比如强制kill进程、断电），这些文件可能不会被自动清理，长期积累下来也会占用不少空间。
  你可以先正常关闭数据库，然后手动查看数据库目录下的这些文件，备份后删除它们，再重新启动数据库，看看空间是否下降。

• 实际行大小计算误差
  你说每行80字节，可能是按数据类型的理论长度算的，但实际存储可能有差异：

  • 字符串类型（VARCHAR、CHAR）如果存的是多字节字符（比如中文、emoji），UTF-8编码下每个字符会占2-4字节，远大于ASCII的1字节；
  • 即使是数值类型，H2也可能有对齐或额外存储开销；
  • 如果有BLOB/CLOB类型，哪怕内容很小，也会有元数据存储开销。
    建议你实际计算几行的总字节数，比如：

  SELECT OCTET_LENGTH(col1) + OCTET_LENGTH(col2) + ... + OCTET_LENGTH(coln) AS row_size
  FROM your_table_name
  LIMIT 10;
  

  再用SUM计算整个表的实际总字节数：

  SELECT SUM(OCTET_LENGTH(col1) + OCTET_LENGTH(col2) + ... + OCTET_LENGTH(coln)) AS total_bytes
  FROM your_table_name;
  

  对比这个值和你理论的22.4MB，看看是不是计算时忽略了某些数据类型的实际开销。

• 页碎片与填充因子
  如果这张表有过频繁的插入、删除、更新操作，会导致数据页出现碎片——比如某个页里只存了少量数据，但还是占用一整页的空间。H2的默认填充因子不是100%，插入数据时会预留部分空间给后续更新，这也会增加磁盘占用。前面提到的COMPACT TABLE命令也能解决页碎片问题，它会重新整理数据页，尽可能填满每个页。

• 系统表与元数据开销
  虽然你只关注这一张表，但H2的系统表（比如INFORMATION_SCHEMA下的表）也会占用一定空间，不过这部分一般不会太大，除非数据库长期运行，积累了大量的元数据（比如历史的表结构变更记录）。可以查询INFORMATION_SCHEMA.TABLES看看系统表的大小，但这大概率不是你问题的元凶。

总结一下，优先排查MVCC版本残留和页碎片，先执行COMPACT TABLE试试，然后检查事务日志文件，再确认实际行大小是否和理论一致，应该就能找到原因了。

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