我的 ibdata 文件非常大，至少在我看来非常大。这是否太过分了，还是还不算太糟？
-rw-rw---- 1 mysql mysql 15G Apr 18 10:11 ibdata1
答案1
当这可能是一个问题时
如果您show table status在表上运行，并且Data_free字段占文件大小的绝大部分ibdata1，那么您可能会浪费大量空间。大量的插入/删除将导致这个问题。如果是这种情况，并且瞬时插入和删除占数据的大部分，那么每个表一个文件就是一个很好的例子。
但这并不是自动的“是”。世界上有很多关于 InnoDB 文件内部碎片的讨论，但将它们作为每个表一个文件放入文件系统只会将碎片转移到文件系统级别，而不是数据库级别。
为什么这通常不是问题
将您的 InnoDB 文件视为文件系统而不是文件。如果您有很多文件，则需要一个大文件系统。
在大多数情况下，文件系统在处理 TB 级数据和不计其数的文件方面表现非常出色。有时它们会遇到索引不佳的问题（例如，在影响性能之前限制目录中的文件数量），但大多数情况下，现代文件系统可以很好地处理 TB 级的数据。
InnoDB 的功能相同。数据文件的大小可能非常大……并且像大型文件系统一样，备份数据时可能会出现问题。但是，就像将文件系统拆分为多个分区无助于解决这个问题一样，尝试操纵 innodb 也无济于事。虽然您可以使用表 1. innodb_file_per_table，我很少推荐它。
就像您的文件系统一样，更好的答案是了解内部限制并在其范围内工作。了解索引并适当应用它们。不要试图拆分 InnoDB，它不是为此而设计的。
由于我很难建设性地传达这个概念，这里有一篇比我写得更好的速读文章：TB 不是大数据，PB 才是。
我记得一张非常非常古老的 MySQL 营销幻灯片，其中客户正在运行一个拥有几 TB 的数据仓库。很多年前。InnoDB 或 MyISAM，两者都可以工作。这是标准的现成的 MySQL 产品。
不用为 15GB 的数据库而烦恼。
答案2
ibdata 文件不会缩小 - 如果您最近删除了一些表或删除了很多行 - 您配置中的 innodb 将不会将可用空间释放回文件系统。我建议您：
- 使用 mysqldump 等备份所有数据
- 添加到 my.cnf innodb_file_per_table 指令
- 重启 mysql
- 删除所有使用 innodb 引擎的数据库
- 停止mysql
- 删除 ibdata 文件
- rm ib_日志文件[01]
- 启动 mysql，检查系统日志是否一切正常
- 重新加载你的转储
通过这种方式，当您删除 innodb 表/数据库时，您将能够回收空间 - 相关的 idb 文件将被立即删除。