デフォルトでは、MySQL InnoDBはすべてのDBのすべてのテーブルを1つのグローバルファイルに保存します。これを変更するには、configでinnodb_file_per_tableを設定します。これにより、テーブルごとに1つのデータファイルが作成されます。

なぜinnodb_file_per_tableデフォルトで有効になっていないのだろうか。それを使用することの欠点はありますか？

これに対する完全な答えがあります。

いったんもしinnodb_file_per_tableは場所に置かれ、そして新しいInnoDBテーブルを使用して縮小することができますALTER TABLE <innodb-table-name> ENGINE=InnoDB';。これは、新しい縮小する.ibd保証のファイルを。

ALTER TABLE <innodb-table-name> ENGINE=InnoDB';innodb_file_per_tableを使用する前に作成されたInnoDBテーブルで実行すると、そのテーブルのデータとインデックスがibdata1ファイルからヤンクされ、ファイルに保存され.ibdます。 。

ibdata1通常、ファイルには4種類の情報が含まれます

• テーブルデータ
• テーブルインデックス
• MVCC（マルチバージョン同時実行制御）データ
  • ロールバックセグメント
  • スペースを元に戻す
• テーブルメタデータ（データディクショナリ）
• ダブルライトバッファー（OSキャッシュへの依存を防ぐためのバックグラウンド書き込み）
• バッファーの挿入（一意でないセカンダリインデックスへの変更の管理）
• をご覧ください Pictorial Representation of ibdata1

ibdata1ファイルをほぼ永久に圧縮する方法は次のとおりです...

ステップ01）MySQLDumpすべてのデータベースをSQLテキストファイル（SQLData.sqlと呼びます）

ステップ02）すべてのデータベースを削除します（mysql、information_schema、およびperformance_schemaスキーマを除く）

ステップ03）mysqlのシャットダウン

ステップ04）/etc/my.cnfに次の行を追加します

[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend

補足：innodb_buffer_pool_sizeの設定が何であれ、innodb_log_file_sizeがinnodb_buffer_pool_sizeの25％であることを確認してください。

• ステップ05）ibdata1、ib_logfile0およびib_logfile1を削除します（削除する前に以下の更新を参照してください！）

この時点で、/ var / lib / mysqlにはmysqlスキーマのみが存在するはずです。

• ステップ06）mysqlを再起動します

これにより、10MBでibdata1が再作成され（オプションを構成しない）、それぞれ1Gでib_logfile0およびib_logfile1が作成されます。

• ステップ07）SQLData.sqlをmysqlにリロードします

ibdata1 成長しますが、テーブルメタデータと断続的なMVCCデータのみが含まれます。

各InnoDBテーブルは外部に存在します ibdata1

mydb.mytableという名前のInnoDBテーブルがあるとします。に入る/var/lib/mysql/mydbと、テーブルを表す2つのファイルが表示されます。

• mytable.frm （ストレージエンジンヘッダー）
• mytable.ibd（のテーブルデータとテーブルインデックスのホームmydb.mytable）

ibdata1 InnoDBデータとインデックスが含まれなくなります。

ではもしinnodb_file_per_tableオプションで/etc/my.cnf、あなたは実行することができOPTIMIZE TABLE mydb.mytableOR ALTER TABLE mydb.mytable ENGINE=InnoDB;、ファイルが/var/lib/mysql/mydb/mytable.ibd実際に縮小します。

私はこれまでMySQL DBAとしてのキャリアでこれまで何度もこれを行いました。実際、これを初めて行ったとき、50GBのibdata1ファイルを50MBに縮小しました。

試してみる。これについてさらに質問がある場合は、私にメールしてください。私を信じて。これは短期的にも長期的にも機能します。

更新2013-07-02 15:08 EDT

この点に関して、他の投稿で更新したという警告がありますが、これを見逃しました：mysqlを再起動してmysqlを停止していたため、innodb_fast_shutdownで回答をもう少し更新しています。現在、コミットされていないすべてのトランザクションには、InnoDBトランザクションログの内部および外部に他の可動部分がある可能性があるため、この1ステップが不可欠です（InnoDBインフラストラクチャを参照）。

innodb_fast_shutdownを2に設定するとログも消去されますが、さらに多くの可動部分が存在し、mysqldの起動中にクラッシュリカバリで選択されることに注意してください。0の設定が最適です。

バグを参照してください。

それを使用することの欠点はありますか？

• より多くのオープンファイル
• オープン/リオープンオーバーヘッド
• .ibdファイルは収縮しない（参照1、2）

大規模なデータベースでは、常にinnodb_file_per_tableを使用します。

MariaDBでは、innodb_file_per_tableがデフォルトで有効になっています。

を使用しないことを選択した理由innodb_file_per_tableは、各テーブルが独自のファイルに配置されるためです。つまり、各テーブルが独自の個別のオーバーヘッド（ファイル署名など）を取得し、MySQLディレクトリ全体の合計サイズが共有テーブルスペースを使用する場合よりも大きくなります。さらに、単一の大きなファイルではなく、複数の小さなファイルがある場合、クラスターのスラックにより無駄なスペースが増えます。

確かに、追加のオーバーヘッドは、特に大きなドライブを使用している場合や巨大なデータベースを持っている場合、物事の大規模なスキームでは大した量ではありませんが、私（およびおそらく多くの「ホームユーザー」） MySQLストアを保持している大規模なクラスターを備えた小さなドライブには、まだ多すぎます。

たとえば、WordPressデータベースと他のいくつかの小さなデータベース（phpBB、dev、一部のAMPテストなど）を含むデータベースストアは、テーブルごとに変換して32MBから50MBに変更しましibdata1たが、必要と10メガバイトの最小値を合計するため、少なくとも 60メガバイト

私が言ったように、これは一部の人々、特に企業にとってはそれほど大きな問題ではないかもしれませんが、あなたがあなたのサイト、ブログなどをホストしているだけのホームユーザーであれば、それは実際に選択のようなものの要因になります多くのホストが合計ディスク使用量に加えてデータベースのサイズを制限するため、ホストプロバイダー。

もう少し情報を追加するだけです

mysql 5.6.6以降ではデフォルトで有効になっています

innodb_file_per_table = 1を使用すると、ドロップテーブルが遅くなることがあります。こちらをご覧ください