MySQL 数据库相对于转储文件有多大？

Question

我正在将 ~52GB 转储恢复到 MySQL 数据库。ibdata1 文件已经超过转储文件的大小，恢复仍然不完整。如果知道 MySQL 转储文件的大小，有没有办法估计 ibdata1 文件的最终大小？

Answer 1

仅从您的问题中的话，我怀疑以下内容：您很可能禁用了innodb_file_per_table。

注意：以下信息基于 innodb_file_per_table 被禁用

当向 InnoDB 表中插入数据时，所有内容及其祖母都位于系统表空间文件中，即 ibdata1。ibdata1 实际上包含什么？

• 表格数据
• 表索引
• 元数据
• MVCC 信息

表数据和索引最初膨胀 ibdata1。元数据只是简单的数据字典 + 在每个表的基础上分配的 tablespace_ids 列表。

什么MVCC（多版本并发控制）？这表示旨在支持事务隔离、回滚、撤消日志、为二级索引插入缓冲区和双写缓冲区的系统对象。

您需要清理 InnoDB 基础架构。我已经写过关于如何以及为什么这样做的 StackExchange 帖子：

• 为什么 InnoDB 将所有数据库存储在一个文件中？
• 建议使用 innodb_file_per_table 吗？
• /sf/answers/283938301/
• https://serverfault.com/a/231400/69271

回到最初的问题，在重新加载时估计 ibdata1 大小的唯一方法是在 mysqldump 之前运行此查询：

SELECT
    data_length/power(1024,3) InnoDBData,
    index_length/power(1024,3) InnoDBIndexes,
    (data_length+index_length)/power(1024,3) InnoDBSize
FROM
    information_schema.tables
WHERE
    engine='InnoDB';

这将报告数据的大小（以 GB 为单位）。在重新加载 ibdata1 后（在您的情况下禁用 innodb_file_per_table），这将是大小估计的经验法则。

从转储文件的大小很难判断，因为数据页和索引页的总大小可能远小于创建转储的 ibdata1 的大小。这种差异将是 MVCC 系统对象（回滚段、撤消日志、双写缓冲区、二级索引插入缓冲区）膨胀产生的剩余空间。从另一个角度来看，数据页的数量可能超过索引页，反之亦然。这可能是由于索引过多、设计不当或数据量过大。