すでに述べたように、-innodb_file_per_table 1つのテーブルを1つのファイルに保存するか、（パーティション化されている場合）多くのファイルに保存するかを決定します。
各アプローチの長所と短所を次に示します（完全なリストである必要はありません）。
Single file per table Multiple files per (partitioned) table
-------------------------------------- --------------------------------------
+ System uses less filehandles - System uses more filehandles
+ One one fsync per second per table - Possibly many more fsync calls (bottleneck)
(less fs overhead (journal etc)) (more fs overhead)
+ Single file uses less space overall - Much larger disk space usage
- Single file fragments badly + Less fragmentation
- Optimize table (et al) takes longer + You can choose to optimize just one file
- One file = one filesystem + You can put heavy traffic files on a fast fs
(e.g. on a solid state disk)
- Impossible to reclaim disk space + possible to emergency-reclaim disk space
in a hurry (truncate table takes long) fast (just delete a file)
- ALTER TABLE can use large % of disk- + rebuilding with ALTER TABLE will use less
space for temp tables while rebuilding temp disk space
一般的に、私はしません 複数のファイルを推奨します。
ただし、ワークロードが大量の断片化につながる場合は、および optimize table 時間がかかりすぎるため、複数のファイルを使用するのが理にかなっています。
スペースの再利用を忘れる
一部の人々は、InnoDBではテーブルファイルが常に拡大し、縮小しないため、行が削除されるとスペースが無駄になるという事実に大騒ぎします。
次に、そのスペースを再利用するためのスキームを考え出します。空きディスク容量が不足しないようにします。 （truncate table x ）。
これは複数のファイルではるかに高速に動作しますが、データベースはほとんど常に拡大し、（ほとんど）縮小することはないため、これはすべて意味がありません。そのため、スペースの再利用は多くの時間（CPUとIO）を浪費します。テーブルを使用している間は完全にロックされます（読み取りと書き込みは許可されません）。
次の月のデータ追加後、90％フルディスク（再利用後50％）が99％フルになることがわかります。
ただし、ALTERTABLEを使用する場合は注意してください...
次のシナリオを検討してください：
-ディスクが60％いっぱいです。
-データベースが50％を占め、他のファイルが10％を占めます。alter table どのテーブルでも、1つのファイルにすべてのテーブルがあるとディスクスペースが不足します。
複数のファイルにある場合は、問題は発生しないはずです（待機中のカフェインの過剰摂取以外）。