Dlaczego warto korzystać z innodb_file_per_table?
Ponieważ łatwiej jest zarządzać pojedynczymi osobami, ponieważ można to zrobić na poziomie pliku. Oznacza to, że nawet jeśli serwer nie działa, nadal możesz kopiować dane, kopiując pliki tabel, natomiast użycie współużytkowanego obszaru tabel oznacza albo skopiowanie wszystkiego, co może być niepotrzebnie ogromne, albo znalezienie sposobu na uruchomienie serwera w celu wyodrębnienia danych ( naprawdę nie chcesz ręcznie wyodrębniać danych za pomocą edytora szesnastkowego).
Ktoś ostrzegł, że nie można po prostu kopiować i wklejać .ibdplików z jednego serwera na inny. Może to być prawda, ale nie powinno to mieć zastosowania do kopii zapasowych na tym samym serwerze (używam tutaj terminu „ kopia zapasowa” w tradycyjnym sensie robienia kopii, tj. Bez radykalnej zmiany całości). Co więcej, ibdata1jest automatycznie odtwarzany przy uruchamianiu (jak widać w kroku usuwaniaibdata1 większości przewodników „konwersja do pliku na tabelę”). W związku z tym nie musisz kopiować ibdata1oprócz .ibdplików (i odpowiadających im .frmplików itp.).
Jeśli próbujesz odzyskać utraconą tabelę, powinno wystarczyć skopiowanie jej .ibdi .frmpliku, a także information_schema(który jest znacznie mniejszy niż ibdata1). W ten sposób możesz umieścić je na fałszywym serwerze i wyodrębnić swój stół bez konieczności kopiowania całej, ogromnej rzeczy.
Jednak żądanie lepszej wydajności jest wątpliwe. … Z innodb_file_per_table potrzeba więcej operacji dyskowych we / wy; jest to znaczące w przypadku skomplikowanych JOIN i ograniczeń FOREIGN KEY.
Nic dziwnego, że wydajność zależeć będzie całkowicie od konkretnej używanej bazy danych. Jedna osoba będzie miała (nawet bardzo) różne wyniki od drugiej.
Prawdą jest, że będzie więcej operacji dyskowych we / wy z plikami na tabelę, ale tylko nieznacznie więcej. Pomyśl o tym, jak działa system.
Zauważysz, że gdy serwer działa, nie możesz przenieść plików danych, ponieważ serwer ma do nich otwarte uchwyty. Wynika to z tego, że kiedy się uruchamia, otwiera je i pozostawia otwarte. Nie otwiera i nie zamyka ich dla każdego zapytania.
W związku z tym na początku, gdy serwer uruchamia się, jest tylko kilka operacji We / Wy; nie podczas działania. Ponadto, chociaż każdy pojedynczy .ibdplik ma swój własny narzut (podpisy plików, struktury itp.), Są one buforowane w pamięci i nie są ponownie odczytywane dla każdego zapytania. Co więcej, te same struktury są odczytywane nawet przy współużytkowanym obszarze tabel, więc nie ma prawie żadnej (jeśli w ogóle) dodatkowej pamięci.
Czy innodb_file_per_table ma wpływ na lepszą wydajność mysql?
W rzeczywistości wydajność może być gorsza .
Podczas korzystania ze wspólnego obszaru tabel operacje odczytu i zapisu mogą czasami / często być łączone, dzięki czemu serwer odczytuje próbkę danych z wielu tabel za jednym razem ibdata.
Jeśli jednak dane są rozłożone na wiele plików, musi wykonać osobną operację we / wy dla każdego z nich osobno.
Oczywiście jest to znów całkowicie zależne od danej bazy danych; rzeczywisty wpływ na wydajność zależeć będzie od wielkości, częstotliwości zapytań i wewnętrznej fragmentacji udostępnionego obszaru tabel. Niektóre osoby mogą zauważyć dużą różnicę, podczas gdy inne mogą nie odczuwać żadnego wpływu.
Obszar tabel jest współdzielony na pojedynczym ibdata; w jaki sposób dedykowane obszary tabel dla oddzielnych tabel mogą zaoszczędzić miejsce na dysku?
To nie. Jeśli już, to trochę zwiększa wykorzystanie dysku.
Nie mam bazy danych o pojemności 60 GB do przetestowania, ale moja „marna” osobista baza danych, która zawiera moją instalację WordPress i kilka małych tabel do użytku osobistego i testowania rozwoju, ważyła około 30 MB podczas korzystania ze wspólnego obszaru tabel. Po przekonwertowaniu go na plik na tabelę nadęty do ~ 85 MB. Nawet po usunięciu wszystkiego i ponownym zaimportowaniu wciąż miał> 60 MB.
Wzrost ten wynika z dwóch czynników:
Absolutne minimum rozmiar ibdata1jest-z jakiegoś powodu-10MB, nawet jeśli nie masz nic, ale information_schemaprzechowywane w nim.
W przypadku wspólnego obszaru tabel ibdata1ma tylko narzuty, takie jak podpisy plików, metadane itp., Ale w przypadku tabeli każdy .ibdplik ma to wszystko. Oznacza to, że suma (nawet przy hipotetycznym <10 MB ibdata1) byłaby nieco większa o co najmniej:
GetTotalSizeofOverhead() * GetNumTables()
Oczywiście nie będą to olbrzymie wzrosty (chyba że używasz hosta, który ogranicza rozmiar bazy danych lub przechowuje je na dysku flash itp.), Ale mimo to zwiększają się i podczas przełączania ( każdej ) tabeli na plik - przy stole można zmniejszyć ibdata1do 10 MB, całkowita suma będzie niezmiennie większa niż była.