回答:
あなたが行かなければならないinnodb_file_per_tableを InnoDBテーブルの現在のインフラストラクチャでの洗浄方法は、いくつかを行う必要があります。
多くのDBホスティングクライアントがMySQLをセットアップし、InnoDBをデフォルト状態のままにしているのを見てきました。これにより、システムテーブルスペース（ibdata1として知られている）が大きく成長します。
innodb_file_per_tableに切り替えた場合でも、.ibdファイルをibdata1から抽出する必要があり、ibdataは縮小しません。たとえば、ibdata1内にmydb.mytableというテーブルがあり、2GBを占有している場合、それを抽出するには次のようにする必要があります。
ステップ01）これを/etc/my.cnfに追加します
[mysqld]
innodb_file_per_tableステップ02） service mysql restart
ステップ03） ALTER TABLE mydb.mytable ENGINE=InnoDB;
これにより、ファイルは/var/lib/mysql/mydb/mytable.ibdになります
残念ながら、変更前にテーブルが占有していた2GBのスペースは回収できません。InnoDBのインフラストラクチャをクリーンアップする方法と理由について、過去の投稿を書きました。
この大きな変更を行ったら、innodb_open_files（デフォルトは300）を増やすことを忘れないでください。それ以外の場合、ディスクアクセスは非常に制限されます。
結合に関しては、結合基準をサポートする適切なインデックスがあることを確認してください。
すべてのDDLはibdataの外部で実行されるため、新規インストールでinnodb_file_per_tableを使用すると、ibdata1の成長が非常に遅くなります。前述のように、InnoDBテーブルは次のように縮小できます。
ALTER TABLE mydb.mytable ENGINE=InnoDB;バックアップに関しては、.ibdファイルのコピーを作成する際には非常に注意してください。どうして？
すべての.ibdファイル内には、tablespace_idと呼ばれる特別な値があります。ibdata1にはtablespace_id値のリストがあります。テーブルの削除と再作成が必要なテーブルメンテナンスを実行する場合、tablespace_idは異なります。このような.ibdファイルのコピーを作成することは、ibdata1のコピーも作成する場合にのみ使用するためにデータベースに統合できます。これは、他のすべてのInnoDBテーブルのtablespace_idを危険にさらします。これを考慮すると、mysqldumpはデータの論理コピーであるため、mysqldumpバックアップを実行することをお勧めします。つまり、バックアップはibdata1の特定の時点とは無関係であり、操作性の問題なしに自由にリロードできます。
彼が言及していないことについて、@ RolandoMySQLDBAに同意してください：バックアップ。
MySQLのバックアップ体制がすべて整っていて、ファイルシステムのバックアップ戦略に.ibdファイルを含めていない場合、これはそれほど重要ではありません。ただし、innodbテーブルに1バイトを追加すると、.ibdテーブルの増分バックアップが発生し、バックアップストレージがすぐに不足することがわかります。
まさにこのような状況にあるアプリケーションがあります。いくつかの大きなテーブルといくつかの小さなテーブルです。
小さなものはそのibdata1ままにしておき、大きなものは独自のファイルに入れました。
私はそうすることでそうします innodb_file_per_tableデフォルトでオンに切り替えだけにテーブルを移動するため一時的にオフにibdata1してALTER TABLE。
ALTER TABLE。私の戦略はinnodb_file_per_table、小さなテーブルを移動しibdata1てから再びオンにするために、定期的にスイッチを入れて、カジュアルにスイッチを切ることです。