何らかの理由で、mysqltunerを実行すると、MySQLサーバーのすべてのInnoDBテーブルがフラグメント化されてリストされます。私は数時間前（OSX Lion）にサーバーをインストールしましたが、バッチファイルからインポートされた大量の新しいデータがサーバーに含まれています。

1つのデータベースのすべてのテーブルをMYISAMに変換してみましたが、断片化されたテーブルの数が十分に減っていることを確認しました。奇妙なことに、これらのテーブルをInnoDBに変換し直すとすぐに、断片化されたテーブルの数が再び増加しました。これは、これまでの私の調査とは対照ALTER TABLE table_name ENGINE=INNODB;的です。これは、実行すると断片化が修正されることを示唆しています。

少しググリングした後、私は走った：

SELECT table_schema, table_name, data_free/1024/1024 AS data_free_MB 
FROM information_schema.tables
WHERE engine LIKE 'InnoDB' AND data_free > 0

これはおそらくすべての断片化されたテーブルをリストします（実際には、断片化されたテーブルカウントのmysqltuner出力と同じ数の結果を返します）。すべての単一のエントリは、data_free_MB列に正確に同じ番号を持っています（現在は7.00000000）。

これは実際に本当の問題ですか、それともmysqltunerが間違っているのですか？問題がある場合、どうすれば修正できますか？

編集

私がばかであり、7MBの断片化が各テーブルではなくファイル全体に対するものであることに、ますます疑わしくなっています。それが事実であるかどうか誰でも確認できますか？

上記の私のコメントのとおり、sqltunerからのすべての出力がエラーを示すわけではありません。スクリプトが問題であることを非常に明確に述べていない限り（通常は次の行にあり、その後に修正の提案が続きます）、それは単なる情報項目です。

innodb_file_per_tableを有効にすると、新しいInnoDBテーブルを外部.ibdファイルに作成するプロトコルをセットアップするだけで済みます。これより前に作成したすべてのInnoDBテーブルは、依然としてibdata1に埋め込まれています。

innodb_file_per_tableを無効にすると、いつでも

ALTER TABLE table_name ENGINE=INNODB;

テーブルのデータとインデックスページをibdata1に追加するだけです。これにより、テーブルが隣接するページに存在し、断片化が解消されます。欠点は、ibdata1が急速に大きくなることです。

勧告

すべてのデータをエクスポートし、ibdata1、ib_logfile0、ib_logfile1を削除して、リロードする必要があります。

これを行う方法と理由を書いた

• Oct 29, 2010：Howto：mysql InnoDBストレージエンジンをクリーンアップしますか？
• Jul 05, 2012：ibdata1を移動、innodb_data_file_pathを設定

UPDATE 2012-08-15 12:05 EDT

mysqltuner.plスクリプト自体を調べたい場合があります。私見それは断片化を測定するために古い式を使用していると思います。mysqltunerが最新バージョンであることを確認してください。

外部に保存されたInnoDBテーブルの断片化の測定については、2012年4月11日にそのことについて投稿しました（2012年4月19日の下部にある更新を参照してください）。