Jak już wspomniałeś -innodb_file_per_table zdecyduje, czy jedna tabela będzie przechowywana w jednym pliku, czy (jeśli jest podzielona na partycje) w wielu plikach.
Oto kilka zalet i wad każdego podejścia (niekoniecznie pełna lista).
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
Ogólnie nie polecam wiele plików.
Jeśli jednak Twoje obciążenie prowadzi do dużej fragmentacji i optimize table trwa zbyt długo, używanie wielu plików będzie miało sens.
Zapomnij o odzyskiwaniu miejsca
Niektórzy ludzie robią dużo zamieszania z powodu faktu, że w InnoDB pliki zawsze rosną i nigdy się nie kurczą, co prowadzi do marnowania miejsca, jeśli wiersze są usuwane.
Następnie wymyślają schematy odzyskiwania tej przestrzeni, tak aby aby nie zabrakło wolnego miejsca na dysku. (truncate table x ).
To będzie działać znacznie szybciej z wieloma plikami, jednak to wszystko jest nonsensem, ponieważ bazy danych prawie zawsze rosną i (prawie) nigdy się nie kurczą, więc całe to odzyskiwanie miejsca będzie marnować dużo czasu (procesor i IO) podczas korzystania z tabeli zostanie w pełni zablokowana (brak możliwości odczytu i zapisu).
Tylko po to, by stwierdzić, że dysk zapełniony w 90% (50% po odzyskaniu) będzie zapełniony w 99% po dodaniu danych w kolejnych miesiącach.
Jednak używając ALTER TABLE strzeż się...
Rozważmy następujący scenariusz:
- Dysk jest zapełniony w 60%.
- Baza danych zajmuje 50%, inne pliki zajmują 10%.
Jeśli wykonasz alter table na dowolnej tabeli zabraknie Ci miejsca na dysku, jeśli masz wszystkie tabele w jednym pliku.
Jeśli masz je w wielu plikach, nie powinieneś mieć problemów (poza przedawkowaniem kofeiny z tego całego czekania).
