データが安定したサイズに達するか、拡大しているテーブルが数十または数百メガバイト単位で増大した場合、OPTIMIZE TABLE ステートメントを使用して、テーブルを再編成し、無駄なスペースを圧縮することを考慮します。 再編成されたテーブルでは、フルテーブルスキャンを実行するために必要なディスク I/O が減ります。 これは、インデックスの使用の改善やアプリケーションコードのチューニングなどのほかの技法が現実的でない場合に、パフォーマンスを向上できる直接的な技法です。

OPTIMIZE TABLE はテーブルのデータ部分をコピーし、インデックスを再構築します。 インデックス内へのデータのパックの改善とテーブルスペース内およびディスク上の断片化の削減からメリットが得られます。 このメリットは各テーブル内のデータによって異なります。 利点が大きいものとそうでないものがあること、またはテーブルの次回の最適化まで、時間の経過とともに利点が減っていくことに気付く場合があります。 テーブルが大きい場合、または再構築されるインデックスがバッファプールに収まらない場合、この操作は遅くなる可能性があります。 大量のデータをテーブルに追加したあとの最初の実行では、多くの場合にその後の実行よりかなり遅くなります。

InnoDB では、長い PRIMARY KEY (長い値を持つ単一カラムまたは長い複合値を形成する複数のカラムのいずれか) があると、大量のディスク領域を無駄にします。 行の主キー値は、同じ行を指すすべてのセカンダリインデックスレコードに複製されます。 (セクション15.6.2.1「クラスタインデックスとセカンダリインデックス」を参照してください。) 主キーが長い場合、AUTO_INCREMENT カラムを主キーとして作成するか、カラム全体ではなく、長い VARCHAR カラムのプリフィクスをインデックス設定します。

可変長の文字列を格納するために、または多くの NULL 値を持つカラムに対して、CHAR の代わりに VARCHAR データ型を使用します。 CHAR(N) カラムは、文字列が短いか、その値が NULL だとしても、データを格納するために常に N 文字を必要とします。 テーブルが小さいほどバッファープールに収まりやすく、ディスク I/O が減ります。

COMPACT 行フォーマット (デフォルトの InnoDB フォーマット) および可変長文字セット (utf8 や sjis など) を使用する場合、CHAR(N) カラムは可変容量の領域を占有しますが、N バイト以上のままです。

大きいか、繰り返しの多い大量のテキストや数値データを格納するテーブルでは、COMPRESSED 行フォーマットを使用することを考慮します。 データをバッファープールに入れたり、フルテーブルスキャンを実行したりするために必要なディスク I/O が減ります。 永続的な決断を下す前に、COMPRESSED と COMPACT の行フォーマットを使用して達成できる圧縮の量を測定してください。