Question

services.profile      optimize        note    Table does not support optimize, doing recreate + analyze instead
services.profile      optimize        error   Creating index 'PRIMARY' required more than 'innodb_online_alter_log_max_size' bytes of modification log. Please try again.
services.profile      optimize        status  Operation failed

该表是300GB大的索引。

变量mysql在工作3小时后抱怨：

innodb_online_alter_log_max_size        5500000000

在那段时间内，表格的写入时间不超过几MB。

innodb / mysql的问题是300GB表的简单OPTIMIZE在“工作”3小时后失败，因为5.5GB的缓冲区已经满了吗？

Answer 1

不要在InnoDB表上使用OPTIMIZE TABLE - 它几乎不提供任何好处。

InnoDB受到某些碎片的影响，但还不足以值得进行碎片整理的停机时间。而且数据很快就会变得支离破碎。

碎片化的主要原因是“块拆分”例如，当您向16KB块添加一行“满”时，该块将被拆分为两个。例如，在一个块中的89行加1行变成例如在两个块中的每一个中的45行。当您继续插入行时，这些（和其他）块会逐渐填满，直到它们再次分裂为止。经过大量此类插入后，表格大约占69％。

所以，你说，这不会减慢很多东西吗？否。点查询深入研究BTree - 一个相对恒定的时间。范围扫描会触发更多块，但扫描的行数不会更改。等

此外，InnoDB将两个相邻的块“太空”组合在一起，从而避免（通常）某些最坏的情况。如果DELETE有很多行，则块可能会变空。这种“结合”可以控制碎片。

如果你的“碎片”指的是分散在磁盘周围的块，那么OPTIMIZE TABLE无法解决这个问题。任何块拆分都将使用“任何地方”的新块。

UPDATE介于INSERT（行中文本增长）和DELETE之间（如果数据缩小）。

（我遗漏了更多细节。）

mysql innodb optimize - 几小时后失败

1 个答案: