MySQL：为什么 ibdata 文件在增长？我们怎样才能缩小它？

Question

即使我们从第一天开始就使用“innodb_file_per_table = 1”。ibdata 文件仍在继续增长。我们数据库的总大小约为 800GB，而 ibdata 文件目前约为 50GB。我们所有的表都是innodb。

当我们使用 innodb_file_per_table 时它如何增长？
可能是 blob、mediumtext 或这些类型的列？
考虑到我们已经使用 innodb_file_per_table，有没有办法缩小这个范围？

Answer 1

表空间增长的一个常见原因是撤销空间。简化：尚未提交的事务会跟踪可以在必要时回滚的更改。请参阅Phil 链接的有关不断增长的表空间的进一步解释的文章。

当然，除了逻辑还原之外，仍然没有办法缩小表空间[参见文档中的减少表空间]。

如果撤消空间是您增长的原因，从 5.6 开始，您可以将撤消日志存储在单独的文件中。要记住的一些事情：

• 这只能在新创建的实例上完成，因此您可以在执行上述逻辑还原时分离撤消空间。
• 你不能改变innodb_undo_tablespaces，所以估计高。
• 您可以更改innodb_undo_logs的数量，因此可以根据您的性能测试进行调整。
• 建议通过指定innodb_undo_directory在 SSD 存储的目录中创建撤消日志
• 直到 5.7，您才能缩小撤消空间的大小。请参阅这篇文章，了解它是如何工作的。
• 一旦分离了撤消空间，就不能降级到低于 5.6 的版本。我怀疑这不是问题，但需要提及。

我的建议：

• 计划升级到 5.7。仅增加性能模式洞察力就值得。
• 确定撤消空间是否真的是表空间增长的原因。很可能是。
• 确定这是否正在增长表空间真的是一个问题：您是否遇到了性能问题？您的磁盘空间是否不足？
• 如果是，请计划逻辑还原以分离撤消空间，意识到更大的数据集将花费更长的时间。相应地计划。

关于移动撤消空间的其他见解：

我可以在现有服务器上的 MySQL 5.6 中将撤消日志移到 ibdata1 之外吗？