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表的简单优化在3个小时的“工作”后失败了，因为5.5gb的缓冲区已经满了？？
1条答案
按热度按时间ubbxdtey1#
不要使用
OPTIMIZE TABLE在innodb表上——它提供的好处很少（如果有的话）。innodb遭受了一些碎片，但还不足以值得停机进行碎片整理。数据很快就会再次变得支离破碎。
碎片化的主要原因是“块分割”，例如，当您将一行添加到一个16kb的“已满”块时，该块被分割为两个。比如说，一个块中的89行加上1行就变成了两个块中的45行。当您继续插入行时，这些（和其他）块会逐渐填满，直到再次拆分。经过大量这样的插入后，表中的内容将占到69%。
所以，你说，这不会让事情慢很多吗？不，点查询会深入到一个btree——一个相对恒定的时间。范围扫描命中更多块，但扫描的行数不变。等。
此外，innodb将合并两个相邻的“太空”的块，从而避免（通常）一些最坏的情况。如果你
DELETE很多行、块可能会变得相当空。这种“组合”可以控制碎片。如果你说的“碎片”指的是散落在磁盘上的块，那么，这是不可治愈的
OPTIMIZE TABLE. 任何块拆分都将使用来自“anywhere”的新块。UPDATE介于INSERT（行中文本的）和DELETE（如果数据缩小）。（我遗漏了更多细节。）