Warum innodb_file_per_table verwenden?
Weil es einfacher ist, einzelne Dateien zu verwalten, da dies auf Dateiebene möglich ist. Dies bedeutet, dass Sie auch dann Daten kopieren können, wenn der Server ausfällt, indem Sie die Tabellendateien kopieren. Wenn Sie einen gemeinsam genutzten Tabellenbereich verwenden, müssen Sie entweder alles kopieren, was unnötig umfangreich sein kann, oder einen Weg finden, den Server zum Extrahieren von Daten zum Laufen zu bringen ( Sie möchten die Daten wirklich nicht manuell mit einem Hex-Editor extrahieren.
Jemand hat gewarnt, dass Sie .ibdDateien nicht einfach von einem Server auf einen anderen kopieren und einfügen können. Dies mag zutreffen, sollte aber nicht für Backups auf demselben Server gelten (ich verwende den Begriff Backup hier im herkömmlichen Sinne, um eine Kopie zu erstellen, dh das Ganze nicht drastisch zu ändern). Darüber hinaus ibdata1wird beim Start automatisch neu erstellt (wie im Löschschrittibdata1 der meisten Handbücher zum Konvertieren in Dateien pro Tabelle zu sehen). Daher müssen Sie nichtibdata1 zusätzlich zu Ihren .ibdDateien (und den entsprechenden .frmDateien usw.) kopieren .
Wenn Sie versuchen, eine verlorene Tabelle wiederherzustellen, sollte es ausreichend sein, ihre .ibdund die .frmDatei sowie information_schema(die viel kleiner ist als ibdata1) zu kopieren . Auf diese Weise können Sie sie in einen Dummy-Server einfügen und Ihre Tabelle extrahieren, ohne das ganze, massive Ding kopieren zu müssen.
Der Anspruch auf bessere Leistung ist jedoch fraglich. … Mit innodb_file_per_table werden mehr Platten-E / A-Operationen benötigt. Dies ist bei komplizierten JOINs und FOREIGN KEY-Einschränkungen von Bedeutung.
Es überrascht nicht, dass die Leistung vollständig von den verwendeten Datenbanken abhängt. Eine Person wird (sogar sehr) unterschiedliche Ergebnisse von einer anderen haben.
Es ist wahr, dass es mit file-per-table mehr Platten-E / A-Operationen geben wird, aber nur geringfügig mehr. Überlegen Sie, wie das System funktioniert.
Sie werden feststellen, dass Sie die Datendateien nicht verschieben können, wenn der Server ausgeführt wird, da der Server über offene Punkte für sie verfügt. Dies liegt daran, dass sie beim Starten geöffnet und geöffnet bleiben. Sie werden nicht für jede einzelne Abfrage geöffnet und geschlossen.
Daher gibt es zu Beginn des Serverstarts nur noch einige weitere E / A-Vorgänge. nicht während es läuft. Während jede einzelne .ibdDatei ihren eigenen Overhead hat (Dateisignaturen, Strukturen usw.), werden sie im Arbeitsspeicher zwischengespeichert und nicht für jede Abfrage erneut gelesen. Darüber hinaus werden dieselben Strukturen auch mit einem gemeinsam genutzten Tabellenbereich gelesen, sodass kaum (wenn überhaupt) mehr Speicher benötigt wird.
Hat innodb_file_per_table einen Einfluss auf eine bessere Leistung von MySQL?
Eigentlich, wenn überhaupt, die Leistung kann in der Tat sein schlechter .
Bei Verwendung eines gemeinsam genutzten Tabellenbereichs können Lese- und Schreibvorgänge manchmal / oft kombiniert werden, sodass der Server ein Datenfeld aus mehreren Tabellen auf einmal liest ibdata.
Wenn die Daten jedoch auf mehrere Dateien verteilt sind, muss für jede Datei eine separate E / A-Operation ausgeführt werden.
Dies hängt natürlich wieder vollständig von der betreffenden Datenbank ab. Die tatsächlichen Auswirkungen auf die Leistung hängen von der Größe, der Häufigkeit der Abfragen und der internen Fragmentierung des gemeinsam genutzten Tabellenbereichs ab. Einige Menschen bemerken möglicherweise einen großen Unterschied, während andere möglicherweise überhaupt keine Auswirkungen sehen.
Der Tablespace wird auf einzelnen ibdata gemeinsam genutzt. Wie können dedizierte Tablespaces für separate Tabellen Speicherplatz sparen?
Es tut nicht. Wenn überhaupt, erhöht es die Festplattennutzung um einiges.
Ich habe keine 60-GB-Datenbank zum Testen, aber meine „dürftige“ persönliche Datenbank, die meine WordPress-Installation und einige kleine Tabellen für den persönlichen Gebrauch und Entwicklungstests enthält, wog bei Verwendung eines gemeinsam genutzten Tabellenbereichs etwa 30 MB. Nachdem es in eine Datei pro Tabelle konvertiert wurde, hatte es eine Größe von ~ 85 MB. Selbst wenn alles gelöscht und erneut importiert wurde, waren es immer noch> 60 MB.
Dieser Anstieg ist auf zwei Faktoren zurückzuführen:
Die absolute Mindestgröße für ibdata1beträgt - aus irgendeinem Grund - 10 MB, auch wenn nichts anderes information_schemagespeichert ist.
Bei einem gemeinsam genutzten Tabellenbereich ist nur ibdata1der Overhead wie Dateisignaturen, Metadaten usw. vorhanden. Bei einer tabellenspezifischen .ibdKonfiguration hat jede einzelne Datei all dies. Dies bedeutet, dass die Summe (auch bei einem hypothetischen Wert <10 MB ibdata1) um mindestens Folgendes etwas größer wäre:
GetTotalSizeofOverhead() * GetNumTables()
Offensichtlich sind dies keine gewaltigen Zuwächse (es sei denn, Sie verwenden einen Host, der die Größe Ihrer Datenbank einschränkt, oder Sie speichern sie auf einem Flash-Laufwerk usw.), aber sie nehmen trotzdem zu, und zwar indem Sie ( jede ) Tabelle in eine Datei umwandeln -pro-Tabelle können ibdata1Sie auf 10 MB verkleinern, die Gesamtsumme wird immer mehr als es war.