Im Vergleich zu gewöhnlichen Benutzerdatentabellen sollten temporäre Tabellen in MySQL/InnoDB für jeden sehr unbekannt sein. Darüber hinaus sind Zeitpunkt und Ort der Erstellung verschiedener temporärer Tabellen nicht festgelegt, was die Rätselhaftigkeit noch verstärkt. Das Schwierigste ist, dass temporäre Tabellen oft zuerst Dateien erstellen und diese dann löschen, ohne etwas zu tun, sodass ein Griff zum Lesen und Schreiben übrig bleibt. Dies erweckt den Eindruck, dass der Drache den Anfang, aber nicht das Ende gesehen hat. Dieser Artikel analysiert detailliert die Verarbeitungsmethoden temporärer Tabellen in verschiedenen Versionen von MySQL. Ich hoffe, dass er für alle hilfreich ist.
Um genau zu sein, gibt es zwei Arten von temporären Tabellen, über die wir oft sprechen. Die eine ist eigentlich eine Tabelle, die zum Speichern der vom Benutzer gesendeten Daten verwendet wird Die Lese- und Schreibschnittstelle der Tabelle muss beim Lesen und Schreiben im Dateisystem vorhanden sein. Der andere Typ sollte zum Speichern von Daten im Zwischenprozess der SQL-Berechnung verwendet werden Wenn die Datei über die Schnittstelle zum Lesen und Schreiben von Dateien ausgeführt wird, wurde die Datei möglicherweise während des Lesens und Schreibens gelöscht, sodass ein Datei-Handle für den Vorgang übrig bleibt.
Verwandte Tutorials: MySQL-Video-Tutorial
Temporäre Tabellen können in temporäre Festplattentabellen und temporäre Speichertabellen unterteilt werden Tabellen und temporäre Dateien sind nur auf der Festplatte vorhanden, nicht im Speicher. Zu den Speicherformen temporärer Tabellen gehören insbesondere die Speicher-Engine und die Temptable-Engine. Der Hauptunterschied besteht in der Speichermethode der Zeichentypen (Varchar, Blob, Texttyp). Letzteres Der Bediener verwendet Speicherplatz mit variabler Länge, wodurch die Speichereffizienz im Speicher verbessert wird und mehr Daten im Speicher verarbeitet werden können, anstatt in eine temporäre Festplattentabelle konvertiert zu werden. Die Memory-Engine ist seit Anfang 5.6 verfügbar und Temptable ist eine neue Engine, die in 8.0 eingeführt wurde. Andererseits gibt es drei Formen temporärer Festplattentabellen: eine ist eine MyISAM-Tabelle, eine ist eine temporäre InnoDB-Tabelle und die andere ist eine Temptable-Dateizuordnungstabelle. Die letzte Methode wird von 8.0 bereitgestellt.
In 5.6 und früheren Versionen wird die temporäre Festplattentabelle in dem in der Datenbank konfigurierten temporären Verzeichnis abgelegt, und das Rückgängigmachen der temporären Festplattentabelle wird zusammen mit dem Rückgängigmachen der normalen Tabelle abgelegt (beachten Sie, dass die Festplatte Die temporäre Tabelle wird nach dem Neustart der Datenbank neu gestartet. Es ist kein Redolog erforderlich, um die Integrität der Transaktion durch die Wiederherstellung nach einem Absturz sicherzustellen. Daher ist es nicht erforderlich, Redolog zu schreiben um Rollback zu unterstützen).
Nach MySQL 5.7 werden die Daten und das Rückgängigmachen der temporären Festplattentabelle getrennt und in einem separaten Tabellenbereich ibtmp1 abgelegt. Der Grund für die Trennung temporärer Tabellen besteht hauptsächlich darin, den Aufwand für die Pflege von Metadaten beim Erstellen und Löschen von Tabellen zu verringern.
Nach MySQL 8.0 werden die Daten der temporären Festplattentabelle separat im temporären Sitzungstabellenbereichspool (ibt-Datei im Verzeichnis #innodb_temp) abgelegt, und das Rückgängigmachen der temporären Tabelle wird in der globalen Tabelle abgelegt Leerzeichen ibtmp1. Eine weitere große Verbesserung besteht darin, dass der von den temporären Tabellendaten der Festplatte in 8.0 belegte Speicherplatz nach dem Trennen der Verbindung für das Betriebssystem freigegeben werden kann, während in Version 5.7 ein Neustart erforderlich ist, bevor er freigegeben werden kann.
Derzeit gibt es zwei Situationen, in denen temporäre Tabellen verwendet werden:
Dies wird von Benutzern explizit für erstellte Tabellen durchgeführt Durch Ausführen des Befehls create temporary table wird der Engine-Typ entweder explizit angegeben oder der Standardkonfigurationswert (default_tmp_storage_engine) verwendet. Die Speichernutzung folgt der Speicherverwaltungsmethode der angegebenen Engine. Beispielsweise werden InnoDB-Tabellen im Pufferpool zwischengespeichert und dann über den Dirty-Thread in die Festplattendatei zurückgeschrieben.
In 5.6 befindet sich die temporäre Festplattentabelle unter tmpdir und der Dateiname ähnelt #sql4d2b_8_0.ibd, wobei #sql ein festes Präfix und 4d2b die hexadezimale Darstellung der Prozessnummer ist. und 8 ist die hexadezimale Darstellung der MySQL-Thread-Nummer (ID in der Prozessliste anzeigen), 0 ist ein inkrementierender Wert beginnend bei 0 für jede Verbindung und ibd ist die temporäre Festplattentabelle von innodb (gesteuert durch Parameter default_tmp_storage_engine). In 5.6 werden nach der Erstellung der temporären Festplattentabelle die entsprechenden FRM- und Engine-Dateien unter tmpdir erstellt und können über den Dateisystembefehl ls angezeigt werden. Nach dem Schließen der Verbindung werden die entsprechenden Dateien automatisch gelöscht. Wenn wir daher im tmpdir von 5.6 viele Dateinamen mit ähnlichem Format sehen, können wir anhand der Dateinamen bestimmen, welcher Prozess und welche Verbindung die temporäre Tabelle verwenden. Diese Technik ist insbesondere bei der Fehlerbehebung anwendbar, wenn das tmpdir-Verzeichnis ebenfalls auftritt viel Platz. Diese Art von temporärer Tabelle, die explizit vom Benutzer erstellt wurde, wird automatisch freigegeben und der Speicherplatz wird beim Lösen der Verbindung wieder an das Betriebssystem zurückgegeben. Das Undolog der temporären Tabelle wird im Undo-Tabellenbereich gespeichert und zusammen mit dem Undo der gewöhnlichen Tabelle platziert. Mit Undo-Rollback-Segmenten können von Benutzern erstellte temporäre Tabellen auch Rollbacks unterstützen.
In 5.7 befindet sich die temporäre Festplattentabelle in der IBTMP-Datei, und der Speicherort und die Größensteuerungsmethode der IBTMP-Datei werden durch den Parameter innodb_temp_data_file_path gesteuert. Die Daten und das Rückgängigmachen explizit erstellter Tabellen befinden sich in ibtmp. Nachdem die Benutzerverbindung getrennt wurde, wird die temporäre Tabelle freigegeben. Durch einfaches Markieren in der IBTMP-Datei wird der Speicherplatz jedoch nicht wieder für das Betriebssystem freigegeben. Wenn Sie Speicherplatz freigeben möchten, müssen Sie die Datenbank neu starten. Darüber hinaus ist zu beachten, dass Sie in 5.6 die erstellte Datei direkt unter tmpdir sehen können, in 5.7 jedoch im Tabellenbereich ibtmp erstellt werden, sodass Sie die spezifische Tabellendatei nicht sehen können. Wenn Sie es anzeigen möchten, müssen Sie die Tabelle INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO anzeigen. Dort befindet sich ein Spaltenname. Den Tabellennamen können Sie hier sehen. Die Namensvorgabe ähnelt der von 5.6, sodass auch Verbindungen, die viel Platz beanspruchen, schnell gefunden werden können.
In 8.0 werden die Daten und das Rückgängigmachen der temporären Tabelle weiter getrennt. Die Daten werden in der IBT-Datei gespeichert (gesteuert durch den Parameter innodb_temp_tablespaces_dir), und das Rückgängigmachen wird weiterhin in der IBTMP-Datei gespeichert (. weiterhin durch den Parameter innodb_temp_data_file_path Steuerung gesteuert). Derjenige, der IBT-Dateien speichert, wird als temporärer Sitzungstabellenbereich bezeichnet, und der IBTMP, der Rückgängig speichert, wird als globaler temporärer Tabellenbereich bezeichnet. Hier finden Sie eine Einführung in den temporären Tabellenbereich „Session“, in dem Daten gespeichert werden. Der temporäre Tabellenbereich für Sitzungen wird auf der Festplatte als eine Reihe von Dateipools angezeigt, die aus IBT-Dateien bestehen. Beim Start wird die Datenbank im konfigurierten Verzeichnis neu erstellt und beim Schließen der Datenbank gelöscht. Beim Start werden standardmäßig 10 IBT-Dateien erstellt, und jede Verbindung verwendet bis zu zwei, eine für die vom Benutzer erstellte temporäre Tabelle und die andere für die implizite temporäre Tabelle, die vom unten beschriebenen Optimierer erstellt wird. Natürlich wird die temporäre Tabelle nur dann erstellt, wenn sie benötigt wird. Wenn sie nicht benötigt wird, wird die IBT-Datei nicht belegt. Wenn alle 10 IBTs verwendet werden, wird die Datenbank weiterhin erstellt, wobei maximal 400.000 erstellt werden. Wenn die Verbindung freigegeben wird, wird die von der Verbindung verwendete IBT-Datei automatisch freigegeben und der Speicherplatz wird zurückgefordert. Wenn Sie den globalen temporären Tabellenbereich recyceln möchten, müssen Sie dennoch einen Neustart durchführen. Da jedoch die Dateien, in denen Daten gespeichert sind, getrennt wurden und dynamisches Recycling unterstützen (d. h. Speicherplatz wird freigegeben, wenn die Verbindung getrennt wird), wurde das Problem der Speicherplatzbelegung, das unter 5.7 lange Zeit allen geplagt hat, erheblich gemildert. Natürlich gibt es noch Raum für Optimierungen. Beispielsweise muss der Speicherplatz freigegeben werden, nachdem die Verbindung getrennt wurde. Theoretisch kann nach bestimmten SQL-Anweisungen (z. B. wenn der Benutzer eine explizit erstellte temporäre Tabelle löscht) viel Speicherplatz freigegeben werden. wird ausgeführt. Wenn Sie außerdem den Tabellennamen anzeigen müssen, sehen Sie sich weiterhin die Tabelle INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO an. Es ist zu beachten, dass explizite temporäre Tabellen unter 8.0 keine komprimierten Tabellen sein können, 5.6 und 5.7 jedoch schon.
Diese Art von temporärer Tabelle ist eine von der Datenbank erstellte Hilfstabelle, um die Ausführung einiger komplexer SQL-Anweisungen zu unterstützen Tabelle erforderlich? , im Allgemeinen vom Optimierer bestimmt. Anders als bei der direkten Erstellung von Festplattendateien für temporäre Tabellen, die explizit von Benutzern erstellt wurden, verwendet der Optimierer zunächst den Speicher der temporären Tabelle, wenn dieser den konfigurierten Speicher überschreitet (min(tmp_table_size, max_heap_table_siz)). , es wird in eine temporäre Festplattentabelle konvertiert. Diese Art von temporärer Festplattentabelle ähnelt einer explizit vom Benutzer erstellten Engine-Typ wird durch den Parameter internal_tmp_disk_storage_engine gesteuert. Im Allgemeinen verwenden etwas komplexere Abfragen, einschließlich, aber nicht beschränkt auf „Ordnen nach“, „Gruppieren nach“, „Eindeutig“ usw., diese implizit erstellte temporäre Tabelle. Benutzer können den Befehl „explain“ verwenden, um zu sehen, ob in der Spalte „Extra“ ein Wort wie „Using temporary“ vorhanden ist. Wenn ja, muss eine temporäre Tabelle verwendet werden.
In 5.6 befindet sich die implizite temporäre Tabelle immer noch unter tmpdir. Während der Ausführung von komplexem SQL können Sie sehen, dass diese temporäre Tabelle gelöscht wird. Es ist erwähnenswert, dass diese implizit erstellte temporäre Tabelle in 5.6 nur mit der MyISAM-Engine verwendet werden kann, d. h. es gibt keinen internal_tmp_disk_storage_engine-Parameter zur Steuerung. Wenn in unserem System nur die innodb-Tabelle vorhanden ist, werden wir daher auch einige Indikatoren für MyISAM-Änderungen sehen. In diesem Fall liegt dies normalerweise an der impliziten temporären Tabelle.
In 5.7 wird die implizite temporäre Tabelle in der ibtmp-Datei erstellt. Nach Abschluss der SQL wird sie zum Löschen markiert, der Speicherplatz wird jedoch bei Bedarf immer noch nicht zurückgegeben zurückgegeben werden, muss die Datenbank neu gestartet werden. Darüber hinaus unterstützt 5.7 den Parameter internal_tmp_disk_storage_engine und Benutzer können InnoDB- oder MYISAM-Tabellen als temporäre Festplattentabellen auswählen.
In 8.0 werden implizite temporäre Tabellen im temporären Tabellenbereich der Sitzung erstellt, d. h. zusammen mit den Daten der vom Benutzer explizit erstellten temporären Tabellen platziert. Wenn eine Verbindung zum ersten Mal eine implizite temporäre Tabelle erfordert, entnimmt die Datenbank eine aus dem Pool bestehend aus IBT-Dateien, die die Verbindung verwenden kann, bis die Verbindung freigegeben wird. Wie oben erwähnt, haben wir auch erwähnt, dass in 8.0 temporären Tabellen, die explizit von Benutzern erstellt wurden, auch ein IBT aus dem Pool zur Verwendung zugewiesen wird. Jede Verbindung verwendet bis zu zwei IBT-Dateien zum Speichern temporärer Tabellen. Wir können INFORMATION_SCHEMA.INNODB_SESSION_TEMP_TABLESPACES abfragen, um den Verbleib der IBT-Datei zu ermitteln. In dieser Tabelle ist jede IBT-Datei eine Zeile, und im aktuellen System gibt es mehrere Zeilen für mehrere IBT-Dateien. Es gibt eine Spalte namens ID. Wenn diese Spalte 0 ist, bedeutet dies, dass dieser IBT nicht verwendet wird. Wenn sie nicht 0 ist, bedeutet dies, dass die Verbindung mit dieser ID verwendet wird. Dies bedeutet, dass die Verbindung mit Prozess-ID 8 diese IBT-Datei verwendet. Darüber hinaus gibt es auch eine Zweckspalte. Der Wert INTRINSIC gibt an, dass die implizite temporäre Tabelle dieses IBT verwendet, und USER gibt an, dass die angezeigte temporäre Tabelle verwendet wird. Darüber hinaus gibt es eine Spaltengröße, die die aktuelle Größe angibt. Benutzer können diese Tabelle abfragen, um die Verwendung temporärer Tabellen in der gesamten Datenbank zu ermitteln, was sehr praktisch ist.
In 5.6 und 5.7 können temporäre Speichertabellen nur die Memory-Engine verwenden. In 8.0 gibt es eine zusätzliche Auswahl an Temptable-Engine. Temptable verwendet in seinem Speicherformat Speicher variabler Länge, wodurch Speicherplatz gespart, die Speichernutzung weiter verbessert und die Anzahl der Konvertierungen in temporäre Festplattentabellen verringert werden kann. Wenn der temporäre Tabellensatz der Festplatte InnoDB oder MYISAM ist, ist eine Konvertierungskopie erforderlich. Um den Verbrauch so weit wie möglich zu reduzieren, schlägt Temptable einen Überlaufmechanismus vor. Wenn die temporäre Speichertabelle die konfigurierte Größe überschreitet, wird die Speicherplatzzuordnungsmethode verwendet, dh eine Datei wird geöffnet und dann gelöscht, sodass eine Datei übrig bleibt Handle für Lese- und Schreibvorgänge. Das Format zum Lesen und Schreiben von Dateien ist dasselbe wie das Format im Speicher, sodass der Konvertierungsschritt übersprungen wird und die Leistung weiter verbessert wird. Beachten Sie, dass diese Funktion nur in der noch nicht veröffentlichten Version 8.0.16 verfügbar ist. Da der Code noch nicht sichtbar ist, können wir seine Implementierung anhand der Dokumentation nur erraten. In 8.0.16 wurde der Parameter internal_tmp_disk_storage_engine entfernt und die temporäre Festplattentabelle kann nur die InnoDB-Form oder die Überlaufform von TempTable verwenden. Aus der Dokumentation gehen wir offenbar hervor, dass die offizielle Empfehlung darin besteht, die neue Engine TempTable zu verwenden. Spezifische Leistungsverbesserungen müssen nach der Veröffentlichung des Codes getestet werden, bevor wir Schlussfolgerungen ziehen können.
Im Vergleich zu temporären Tabellen sind temporäre Dateien möglicherweise für jedermann unbekannter. Temporäre Dateien werden häufiger in Szenarien zum Zwischenspeichern und Sortieren von Daten verwendet. Unter normalen Umständen werden die zwischengespeicherten oder sortierten Daten zunächst im Speicher abgelegt. Wenn der Speicher nicht gespeichert werden kann, wird die temporäre Datei auf der Festplatte verwendet. Die Verwendung temporärer Dateien unterscheidet sich von der Verwendung allgemeiner Tabellen. Nachdem eine allgemeine Tabelle erstellt wurde, wird mit dem Lesen und Schreiben der Datei begonnen. Die Verwendung temporärer Dateien unterscheidet sich jedoch (Verwenden Sie die Systemfunktion mkstemp), rufen Sie sofort unlink auf, um die Datei zu löschen, schließen Sie die Datei jedoch nicht und verwenden Sie dann das ursprüngliche Handle, um die Datei zu bedienen. Dies hat den Vorteil, dass bei einem abnormalen Prozessabsturz keine temporären Dateien zurückbleiben, da diese nicht gelöscht wurden. Die Nachteile liegen jedoch auch auf der Hand. Wir können die Datei nicht sehen, wenn wir den Befehl ls im Dateisystem verwenden Verwenden Sie lsof +L1, um Dateien mit diesem gelöschten Attribut anzuzeigen.
Derzeit verwenden wir temporäre Dateien hauptsächlich in den folgenden Szenarien:
Im Prozess der Online-DDL gibt es solche Viele Operationen müssen die ursprüngliche Tabelle rekonstruieren, verschiedene sekundäre Indizes müssen im Speicher sortiert werden und erfordern einen externen Sortieralgorithmus. Während dieses Vorgangs müssen temporäre Dateien erstellt werden. Im Allgemeinen entspricht der benötigte Platz in etwa dem des Originaltisches. Es wird jedoch sofort nach der Verwendung bereinigt. Wenn Sie DDL ausführen, müssen Sie daher genügend Speicherplatz reservieren. Benutzer können den Pfad zu dieser Sortierdatei angeben, indem sie innodb_tmpdir angeben. Dieser Parameter kann dynamisch geändert werden und wird im Allgemeinen auf einen Pfad mit ausreichend Speicherplatz gesetzt. Der Name der temporären Datei ähnelt im Allgemeinen ibXXXXXX, wobei ib ein festes Präfix und XXXXXX eine zufällige Kombination aus Groß- und Kleinbuchstaben und Zahlen ist.
Beim Online-DDL ermöglichen wir Benutzern, DML-Vorgänge für die Originaltabelle auszuführen, also hinzuzufügen, zu löschen, zu ändern und abzufragen. Wir können nicht direkt in die Originaltabelle einfügen, daher benötigen wir einen Ort, an dem wir die Änderungsvorgänge in der Originaltabelle aufzeichnen und sie nach Abschluss der DDL auf die neue Tabelle anwenden können. Der Ort, an dem dies aufgezeichnet wird, ist das Online-Protokoll. Wenn es nur wenige Änderungen gibt, kann es natürlich direkt im Speicher gespeichert werden (der Parameter innodb_sort_buffer_size kann gesteuert werden, und dieser Parameter steuert auch die Größe jedes Lese- und Schreibvorgangs Block des Online-Protokolls). Dieses Onlineprotokoll wird auch in einer temporären Datei gespeichert, die in innodb_tmpdir erstellt wird. Die maximale Größe wird durch den Parameter innodb_online_alter_log_max_size gesteuert. Wenn es diese Größe überschreitet, schlägt DDL fehl. Der Name der temporären Datei ähnelt auch dem Namen der oben erwähnten temporären Sortierdatei.
In der letzten Phase der Online-DDL müssen alle dabei generierten sortierten Dateien und DML auf eine Zwischendatei angewendet werden. Der Name der Zwischendatei ähnelt #sql-ib53-522550444.ibd, wobei #sql-ib ein festes Präfix ist , 53 ist die Tabellen-ID der InnoDB-Ebene und 522550444 ist eine zufällig generierte Zahl. Gleichzeitig wird auch eine FRM-Datei auf der Serverebene generiert (in 8.0 nicht verfügbar). Der Dateiname ähnelt #sql-4d2b_2a.frm, wobei #sql ein festes Präfix und 4d2b die hexadezimale Darstellung von ist die Prozessnummer und 2a ist die hexadezimale Darstellung der Nummer (ID in Show Processlist). Daher können wir diese Namensregel auch verwenden, um herauszufinden, welcher Thread DDL ausführt. Hierbei ist zu beachten, dass es sich bei der hier erwähnten Zwischendatei tatsächlich um eine temporäre Tabelle und nicht um die oben erwähnte temporäre Datei handelt. Diese Zwischendateien können über ls angezeigt werden. Im letzten Schritt des DDL werden die beiden temporären Dateien wieder in ihre ursprünglichen Tabellennamen umbenannt. Aufgrund dieser Funktion können bei einem Absturz der Datenbank mittendrin nutzlose Restdateien auf der Festplatte zurückbleiben. In diesem Fall können Sie zunächst die FRM-Datei in denselben Namen wie die IBD-Datei umbenennen und dann DROP TABLE#mysql50##sql-ib53-522550444` verwenden, um die verbleibenden Dateien zu bereinigen. Beachten Sie, dass beim direkten Löschen der ibd-Datei ohne Verwendung des Drop-Befehls möglicherweise noch Restinformationen im Datenwörterbuch vorhanden sind, was nicht sehr elegant ist. Natürlich werden in 8.0 aufgrund der Verwendung des Atomic Data Dictionary solche Restdateien nicht angezeigt.
BinLog wird nur in die Datei geschrieben, wenn die Transaktion übermittelt wird. Vor der Übermittlung wird sie im Speicher abgelegt (gesteuert durch Parameter). binlog_cache_size) Wenn der Speicher langsamer wird, wird eine temporäre Datei erstellt. Die Verwendungsmethode besteht darin, sie zuerst über mkstemp zu erstellen und dann die Verknüpfung direkt aufzuheben, sodass ein Handle zum Lesen und Schreiben übrig bleibt. Der temporäre Dateiname ähnelt MLXXXXXX, wobei ML ein festes Präfix und XXXXXX eine zufällige Kombination aus Groß- und Kleinbuchstaben und Zahlen ist. Wenn das BinLog einer einzelnen Transaktion zu groß ist, kann dies dazu führen, dass das gesamte BinLog zu groß wird, was sich auf die Synchronisierung auswirkt. Daher müssen wir die Transaktionsgröße so weit wie möglich kontrollieren.
Einige Operationen werden zusätzlich zur Verwendung impliziter temporärer Tabellen auf der Engine-Ebene zur Unterstützung der Berechnung komplexer SQL auch verwendet Auf der Serverebene erstellt. Temporäre Dateien werden zur Unterstützung verwendet, z. B. „Reihenfolge nach Vorgang“, wodurch die Dateisortierungsfunktion aufgerufen wird. Diese Funktion verwendet auch zunächst Speicher (sort_buffer_size) zum Sortieren. Wenn dieser nicht ausreicht, erstellt sie eine temporäre Datei, um das Sortieren zu unterstützen. Der Dateiname ähnelt MYXXXXXX, wobei MY ein festes Präfix und XXXXXX eine zufällige Kombination aus Groß- und Kleinbuchstaben und Zahlen ist.
Bei der BinLog-Replikation werden die Daten aus der Datei importiert, wenn der Befehl „Daten laden“ in der Hauptdatenbank verwendet wird , schreibt die Datenbank die gesamte Datei in das RelayLog und überträgt sie dann an die Standby-Datenbank. Die Standby-Datenbank analysiert das RelayLog, extrahiert die entsprechende Load-Datei und wendet sie dann auf die Standby-Datenbank an. Der Speicherort dieser Datei in der Standby-Datenbank wird durch den Parameter slave_load_tmpdir gesteuert. Das Dokument empfiehlt, dieses Verzeichnis nicht im Speicherverzeichnis der physischen Maschine oder einem Verzeichnis zu konfigurieren, das nach dem Neustart gelöscht wird. Da die Replikation auf dieser Datei basiert, wird die Replikation unterbrochen, wenn sie versehentlich gelöscht wird.
Zusätzlich zu den oben genannten Orten gibt es noch mehrere andere Orte, an denen temporäre Dateien ebenfalls verwendet werden:
*** tmpdir: *** Dieser Parameter ist die Konfiguration des temporären Verzeichnisses. In 5.6 und früheren Versionen werden temporäre Tabellen/Dateien hier abgelegt Standard. Dieser Parameter kann mit mehreren Verzeichnissen konfiguriert werden, sodass temporäre Tabellen/Dateien nacheinander in verschiedenen Verzeichnissen erstellt werden können. Wenn verschiedene Verzeichnisse auf verschiedene Festplatten verweisen, kann der Zweck der Auslagerung erreicht werden.
*** innodb_tmpdir: *** Dieser Parameter wird nur zum Sortieren temporärer Dateien in DDL verwendet. Es nimmt viel Platz ein, daher wird empfohlen, es separat zu konfigurieren. Dieser Parameter kann dynamisch gesetzt werden und ist auch eine Sitzungsvariable.
*** Slave_load_tmpdir: *** Dieser Parameter wird hauptsächlich beim Konfigurieren des temporären Dateispeicherorts der Sicherungsbibliothek beim Laden von Daten in die BinLog-Replikation verwendet. Da die Datenbank nach einem Absturz weiterhin auf das Laden von Datendateien angewiesen ist, wird empfohlen, kein Verzeichnis zu konfigurieren, das Daten nach dem Neustart löscht.
*** internal_tmp_disk_storage_engine: *** Wenn eine implizite temporäre Tabelle in eine temporäre Festplattentabelle konvertiert wird, ist die verwendete Engine standardmäßig nur MyISAM und InnoDB. Wird nur von Version 5.7 und höher unterstützt. Dieser Parameter wurde nach Version 8.0.16 gelöscht.
*** internal_tmp_mem_storage_engine: *** Die Speicher-Engine, die verwendet wird, wenn sich die implizite temporäre Tabelle im Speicher befindet. Sie können zwischen „Memory“ und „Temptable Engine“ wählen. Es wird empfohlen, die neue Temptable-Engine zu wählen.
*** default_tmp_storage_engine: *** Die standardmäßige explizite temporäre Tabellen-Engine, d. h. die Engine für temporäre Tabellen, die von Benutzern über SQL-Anweisungen erstellt wurden.
*** tmp_table_size: *** min(tmp_table_size, max_heap_table_size) ist die Speichergröße der impliziten temporären Tabelle. Wenn sie diesen Wert überschreitet, wird sie in eine temporäre Festplattentabelle konvertiert.
*** max_heap_table_size: *** Die Speichergrenzgröße der vom Benutzer erstellten Speichertabelle.
*** big_tables: *** Das Konvertieren einer temporären Speichertabelle in eine temporäre Festplattentabelle erfordert einen Konvertierungsvorgang, der in verschiedene Engine-Formate konvertiert werden muss. Wenn wir im Voraus wissen können, dass zum Ausführen einer bestimmten SQL eine temporäre Festplattentabelle erforderlich ist, das heißt, dass der Speicher definitiv nicht ausreicht, können wir diesen Parameter so festlegen, dass der Optimierer die Verwendung der temporären Speichertabelle überspringt und die Festplatte direkt verwendet temporäre Tabelle, um den Overhead zu reduzieren.
*** temptable_max_ram: *** Dieser Parameter ist erst nach 8.0 verfügbar. Er wird hauptsächlich verwendet, um die Speichergröße für die Temptable-Engine anzugeben. Nach Überschreitung wird sie entweder in eine temporäre Festplattentabelle konvertiert oder verwendet eingebauter Überlaufmechanismus.
*** temptable_use_mmap: *** Ob der Überlaufmechanismus von Temptable verwendet werden soll.
Die temporären Tabellen und temporären Dateien von MySQL sind tatsächlich ein relativ komplexes Thema, an dem viele Module beteiligt sind, und der Zeitpunkt des Auftretens ist schwer zu erfassen, was im Vergleich zu gewöhnlichen Tabellen zu Problemen bei der Fehlerbehebung führt . Es ist ziemlich schwierig. Den Lesern wird empfohlen, den Code sorgfältig zu studieren, um schwierige Probleme zu lokalisieren, die online auftreten können.
Das obige ist der detaillierte Inhalt vonZusammenfassung temporärer Tabellen für das MySQL-Lernen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
MySQL ändert den Namen der Datentabelle
MySQL erstellt eine gespeicherte Prozedur
Der Unterschied zwischen Mongodb und MySQL
So überprüfen Sie, ob das MySQL-Passwort vergessen wurde
MySQL-Datenbank erstellen
MySQL-Standard-Transaktionsisolationsstufe
Der Unterschied zwischen SQL Server und MySQL
mysqlPasswort vergessen
