optimize table
サイズが約11Gigのテーブルの1つに対してコマンドを実行すると、最適化プロセスが完了した直後に、驚くほど使用済みのディスク領域が2Gig増加しました。最適化によってスペースが再利用されることを期待します。
何が起こっていますか?
最適化が完了した後、MySQL CPUの使用率は、24コアマシンでの負荷平均18〜20の場合よりも2〜3倍高くなりました。 CPUと負荷の平均は、数時間後にわずかに低下しましたが、それでも通常よりは高くなっています。似たような経験はありましたか?ありがとう。
私は同じ経験をしました。解決策は、次のコマンドを使用してテーブルを再構築することです。
ALTER TABLE my_table ENGINE=TokuDB ROW_FORMAT=TOKUDB_SMALL;
TOKUDB_SMALL
をお好みの圧縮アルゴリズムに置き換えます。
InnoDBでは、OPTIMIZE TABLE
コマンドは単純なALTER
を実行します。しかし、TokuDBではサポートされておらず、テーブルスペースは再利用されません。 ENGINE=TOKUDB
を使用してALTER
を強制することで、これをTokuDBの手に負わず、MySQLサーバーにTokuDBに(本当に)新しいテーブルを作成するように指示させます。
TokuDBの最適化動作は、特定のテーブルのすべてのフラクタルツリーインデックスのすべてのノードをダーティにすることです。次のチェックポイントが完了するまで古いバージョンのノードを保持するため、ファイルシステム内のファイルのサイズが大きくなる可能性があります。これは、ノードがダーティになったりディスクに書き込まれたりする時間や、チェックポイントが完了するまでにかかる時間によって異なります。その場合は、2番目の最適化テーブルコマンドを使用すると、通常、元の(または小さい)サイズに戻ります。
最適化テーブルを使用してフォローアップすることをお勧めする1つの操作は、すべてのノードを新しい圧縮形式にすばやく書き換えることができるため、圧縮を変更する場合です。