it-swarm.com.de

Warum innodb_file_per_table verwenden?

Es gibt viele Artikel, die (IMHO natürlich) die Notwendigkeit von innodb_file_per_table. Ich verstehe das mit innodb_file_per_table sollte es eine bessere Kontrolle über die einzelnen Tabellen geben; wie jede Tabelle einzeln sichern. Der Anspruch auf bessere Leistung ist jedoch fraglich.

In meinem Test gibt es keinen Unterschied in der Leistung von innodb_file_per_table und ibdata1 für eine Datenbank von 60 GB. Natürlich war es ein einfacher Test mit normalen Abfragen, und bei komplizierten Abfragen im wirklichen Leben kann die Situation anders sein (aus diesem Grund habe ich diese Frage gestellt). 64-Bit-Linux mit ext4 kann große Dateien effektiv verarbeiten.

Mit innodb_file_per_table sind mehr Festplatten-E/A-Operationen erforderlich; und dies ist signifikant in komplizierten JOINs und FOREIGN KEY Einschränkungen.

Der Tablespace wird für einzelne ibdata freigegeben. Wie können dedizierte Tablespaces für separate Tabellen Speicherplatz sparen? Natürlich ist es mit ALTER einfacher, Tabellenplatz für jede Tabelle freizugeben, aber es ist immer noch ein teurer Prozess (mit Tabellensperre).

FRAGE : Tut innodb_file_per_table wirkt sich auf eine bessere Leistung von MySQL aus? Wenn ja, warum?

28
Googlebot

Ich denke nicht, dass es um Leistung geht, sondern um Management.

Mit einer separaten Datei pro Tabelle können Sie beispielsweise verschiedene Datenbanken auf verschiedenen Speichergeräten speichern.

Sie können den Fall sehr großer Datenbanken in Dateisystemen behandeln, die keine großen Dateien verarbeiten können (verschieben Sie das Problem zumindest, bis eine Tabelle die Dateigrößenbeschränkung erreicht).

Sie haben kein unkontrolliertes Tablespace-Wachstum. Wenn Sie einige große Tabellen löschen, bleibt die Datei ibdata klein.

Ein Aspekt, der sich auf die Leistung auswirken kann, ist die Fragmentierung von Tabellendaten und Indizes, die pro Tabelle begrenzt ist. Aber das muss getestet werden, um bestätigt zu werden.

19
ypercubeᵀᴹ

Warum innodb_file_per_table verwenden?

Weil es einfacher ist, einzelne Personen zu verwalten, da dies auf Dateiebene erfolgen kann. Dies bedeutet, dass Sie auch bei ausgefallenem Server Daten kopieren können, indem Sie die Tabellendateien kopieren, während die Verwendung eines gemeinsam genutzten Tabellenbereichs entweder das Kopieren von allem bedeutet, was unnötig massiv sein kann, oder Suche nach einer Möglichkeit, den Server zum Extrahieren von Daten zum Laufen zu bringen (Sie möchten die Daten wirklich nicht manuell mit einem Hex-Editor extrahieren).

Jemand warnte dass Sie nicht einfach .ibd Dateien von einem Server auf einen anderen kopieren und einfügen können. Dies mag zutreffen, sollte jedoch nicht für Sicherungen auf demselben Server gelten (ich verwende hier den Begriff backup im herkömmlichen Sinne, eine Kopie zu erstellen, dh sich nicht drastisch zu ändern das ganze Ding). Darüber hinaus wird ibdata1 Beim Start automatisch neu erstellt (wie im Schritt zum Löschen von ibdata1 der meisten Anleitungen zum Konvertieren in Dateien pro Tabelle zu sehen ist ). Als solches müssen Sie nicht zusätzlich zu Ihren ibdata1 - Dateien (und den entsprechenden .ibd Usw. .frm Kopieren .dateien).

Wenn Sie versuchen, eine verlorene Tabelle wiederherzustellen, sollte es ausreichen, die Dateien .ibd Und .frm Sowie information_schema (Was viel ist) zu kopieren kleiner als ibdata1). 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 sind mehr Festplatten-E/A-Vorgänge erforderlich. 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) andere Ergebnisse haben als eine andere.

Es ist wahr, dass es mehr Datenträger-E/A-Operationen mit Datei pro Tabelle geben wird, aber nur geringfügig mehr. Überlegen Sie, wie das System funktioniert.

  • Für eine monolithische Datenbank:

    1. Server wird gestartet
    2. ibdata1 Wird geöffnet
    3. Header und Metadaten werden gelesen
    4. Strukturen und Metadaten werden im Speicher zwischengespeichert
    5. Abfragen passieren
      1. Der Server greift auf die Festplatte zu und liest die Daten aus dem bereits geöffneten ibdata1
      2. Der Server kann die Daten im Speicher zwischenspeichern
  • Für eine Datenbank pro Tabelle:

    1. Server wird gestartet
    2. ibdata1 Wird geöffnet
    3. Header und Metadaten werden gelesen
    4. Jede einzelne .ibd Datei wird geöffnet
    5. Header- und Metadaten werden aus jeder .ibd - Datei gelesen
    6. Strukturen und Metadaten werden im Speicher zwischengespeichert
    7. Abfragen passieren
      1. Der Server greift auf die Festplatte zu und liest die Daten aus der bereits geöffneten Datei .ibd
      2. Der Server kann die Daten im Speicher zwischenspeichern

Sie werden feststellen, dass Sie die Datendateien bei Ausführung des Servers nicht verschieben können, da der Server über offene Handles verfügt. Dies liegt daran, dass es beim Start geöffnet und geöffnet bleibt. Sie werden nicht für jede einzelne Abfrage geöffnet und geschlossen.

Daher gibt es zu Beginn des Serverstarts nur einige weitere E/A-Vorgänge. nicht während es läuft. Während jede einzelne .ibd - Datei einen eigenen Overhead hat (Dateisignaturen, Strukturen usw.), werden sie im Speicher zwischengespeichert und nicht für jede Abfrage erneut gelesen. Darüber hinaus werden dieselben Strukturen auch bei einem gemeinsam genutzten Tabellenbereich gelesen, sodass kaum (wenn überhaupt) mehr Speicher erforderlich ist.

Hat innodb_file_per_table einen Einfluss auf eine bessere Leistung von MySQL?

Wenn überhaupt, kann die Leistung tatsächlich sei schlechter sein.

Bei Verwendung eines gemeinsam genutzten Tabellenbereichs können Lese- und Schreibvorgänge manchmal/häufig kombiniert werden, sodass der Server ein Datenfeld aus mehreren Tabellen auf einmal von ibdata liest.

Wenn die Daten jedoch auf mehrere Dateien verteilt sind, muss für jede einzelne eine separate E/A-Operation ausgeführt werden.

Dies hängt natürlich wieder vollständig von der jeweiligen Datenbank ab. Die Auswirkungen auf die tatsächliche 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 für einzelne Ibdata freigegeben. Wie können dedizierte Tablespaces für separate Tabellen Speicherplatz sparen?

Es tut nicht. Wenn überhaupt, erhöht es die Festplattennutzung etwas.

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 ~ 30 MB Bei Verwendung eines gemeinsam genutzten Tabellenbereichs. Nach der Konvertierung in eine Datei pro Tabelle wurde der Wert auf ~ 85 MB aufgebläht. 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 ibdata1 Beträgt aus irgendeinem Grund 10 MB, selbst wenn nur information_schema Gespeichert ist drin.

  • Bei einem gemeinsam genutzten Tabellenbereich hat nur ibdata1 Overhead wie Dateisignaturen, Metadaten usw., aber bei jeder Tabelle hat jede einzelne .ibd Datei all dies. Dies bedeutet, dass die Summe (selbst bei einem hypothetischen <10 MB ibdata1) Zumindest um etwas größer wäre:

    GetTotalSizeofOverhead() * GetNumTables()
    

Offensichtlich werden diese nicht große Erhöhungen sein (es sei denn, Sie verwenden einen Host, der Ihre Datenbankgröße begrenzt oder sie auf einem Flash-Laufwerk speichert usw.), aber sie sind Erhöhungen Wenn Sie jedoch ( jede ) Tabelle auf "Datei pro Tabelle" umschalten, können Sie ibdata1 auf 10 MB verkleinern. Die Gesamtsumme beträgt jedoch immer mehr als es war.

14
Synetech

Dies ist mein Grund, IMMER innodb_file_per_table zu verwenden:

Ohne Datei pro Tabelle wird die ibdata-Datei niemals komprimiert, verkleinert oder verkleinert. Nicht, wenn Sie eine Zeile löschen, eine Tabelle oder eine Datenbank löschen. 2 GB Daten können in kürzester Zeit zu einer 20 GB-Datei werden, wenn Sie ein aktives Warteschlangensystem haben.

Angenommen, Sie möchten vor einer Änderung eine Sicherungskopie Ihrer aktuellen 1-GB-Tabelle erstellen und diese anschließend löschen. Sie haben ein GB nicht genutzten Speicherplatz in Ihren Ibdata. Schade.

Es gibt wahrscheinlich endlose Beispiele für Fälle, in denen temporäre Maßnahmen die einzelne Datendatei aufblasen, aber es genügt zu sagen, dass es meiner Meinung nach nie einen Grund gibt, innodb_file_per_table NICHT zu verwenden

Hier ist auch ein guter Beitrag zum Lesen: http://code.openark.org/blog/mysql/reasons-to-use-innodb_file_per_table

11
randomx

Mein Grund, warum m innodb_file_per_table nicht zu verwenden ist Leistung.

Ich habe einige Tests für unsere Datenbank mit 450 Tabellen unter MySQL 5.5.45 Linux CentOS Release 6.7 durchgeführt

Für Komponententests, die vor jedem Test Fixtures in die Datenbank einfügen (nicht jedes Mal alle Tabellen verwenden) und auch selbst testen, funktioniert die Datenbank viel (Einfügen, Aktualisieren, Löschen, Auswählen) das Leistung war 3-5x besser wenn Datenbanktabellen nicht in mehr Dateien aufgeteilt wurden.

Ich empfehle, Ihre Datenbank mit Abfragen zu testen, die Sie verwenden möchten, und sie zu vergleichen, bevor Sie sich für die Verwendung von innodb_file_per_table entscheiden

Vielleicht können Sie herausfinden, dass Sie für Produktionsserver innodb_file_per_table verwenden können, aber für CI-Umgebungen (setzt die Integration fort), die Unit-Tests starten (verwendet häufig DB), und Entwickler, die Unit-Tests häufig starten, ist es aus Leistungsgründen besser, sie nicht zu verwenden.

5
Tomor

Gemäß dem folgenden Artikel geht es bei der Leistung nicht um die Verwaltung von Daten (Rohoperationen selbst), sondern um das Erstellen und Löschen von Objekten.

innodb_file_per_table macht das massive Erstellen und Löschen von Objekten langsamer als das Speichern von ibdata und für die Produktion nicht anwendbar, sollte aber für kontinuierliche Tests relevant sein.

https://www.percona.com/blog/2015/02/24/mysqls-innodb_file_per_table-slowing/

2
Flavio Peinado

Dadurch werden die Daten besser verwaltet, da Sie nicht genutzten Speicherplatz zurückgewinnen können, was sehr gut ist.

Ich denke, wenn Ihre Datenbank hauptsächlich für ausgewählte Abfragen verwendet wird, hat dies keinen großen Einfluss auf die Leistung. Es muss immer noch ungefähr die gleiche Datenmenge gelesen werden. Ich denke nicht, dass es wichtig ist, aus welchen Dateien die Daten gelesen werden.

Dies kann jedoch die Leistung einer Datenbank verschlechtern, die viele Einfügungen und Aktualisierungen vornimmt. Dies liegt daran, dass mysql nach dem Festschreiben einer Transaktion fsync () für die Speicherdatei aufruft. Wenn es eine einzelne Datei gibt, wird ein Anruf getätigt und auf den Abschluss des Anrufs gewartet. Wenn es viele Dateien gibt, muss der Aufruf mehrmals ausgeführt werden und gewartet werden, bis alle diese Aufrufe zurückgegeben wurden, bevor der Commit-Befehl zurückgegeben werden kann.

Hier ist ein Beitrag von jemandem, bei dem dieses Problem aufgetreten ist: http://umangg.blogspot.com/2010/02/innodbfilepertable.html

2
Sarel Botha

IMHO ist es besser, innodb_file_per_table zu verwenden, es ist sicherer. Wenn Sie es nicht verwenden, können Probleme auf FAT32-Systemen auftreten, auf denen nur 4 GB Dateien zulässig sind. Ich habe einen Artikel darüber in slowakischer Sprache geschrieben ( https://www.itsoft.sk/preco-sa-neuvolni-miesto-na-disku-po-zmazani-mysql-tabulky/ ).

1