Nehmen Sie MySQL als Beispiel, um die militärischen Vorschriften für Datenbanken besser zu verstehen.

Die Datenbank ist immer der kritischste Teil der Anwendung. Gleichzeitig wird die Datenbank oft zu einem Engpass, wenn die Datenbanktabellen und -indizes zu Beginn nicht gut gestaltet sind wird horizontal erweitert und Unterdatenbanken und Tabellen werden gestört.

Für Internetunternehmen wird im Allgemeinen die MySQL-Datenbank verwendet.

1. Die Gesamtarchitektur der Datenbank

Schauen wir uns zunächst die Gesamtarchitektur der MySQL-Daten wie folgt an:

Das ist Ein sehr klassisches Bild Das MySQL-Systemarchitekturdiagramm zeigt die Funktionen jedes Teils von MySQL anhand dieses Diagramms.

Wenn der Client eine Verbindung zur Datenbank herstellt, sieht er sich zunächst dem Verbindungspool gegenüber, der zur Verwaltung von Benutzerverbindungen und zur Durchführung bestimmter Authentifizierungen und Autorisierungen verwendet wird.

Nachdem die Verbindung zur Datenbank hergestellt wurde, sendet der Client SQL-Anweisungen und das SQL-Schnittstellenmodul akzeptiert die SQL-Anweisungen des Benutzers.

SQL-Anweisungen müssen häufig strenge Grammatikregeln einhalten, daher ist ein Grammatikparser zum Parsen der Anweisung erforderlich. Das Prinzip des Parsens der Grammatik entspricht dem Kompilierungsprinzip, von einer Anweisung bis zu einem Syntaxbaum.

Die Abfragen, zu denen der Benutzer gehört, können optimiert werden, sodass der schnellste Abfragepfad ausgewählt werden kann. Dies ist die Rolle des Optimierers.

Um die Abfrage zu beschleunigen, gibt es ein Abfrage-Cache-Modul. Wenn der Abfrage-Cache ein Treffer-Abfrageergebnis hat, kann die Abfrageanweisung Daten direkt aus dem Abfrage-Cache abrufen.

Alle oben genannten Komponenten sind die Datenbankdienstschicht, gefolgt von der Datenbank-Engine-Schicht. Die aktuelle Mainstream-Datenbank-Engine ist InnoDB.

Für alle Änderungen an der Datenbank wird auf der Datenbankdienstschicht ein Binärprotokoll aufgezeichnet, das die Grundlage für die primäre und sekundäre Replikation bildet.

Für die Datenbank-Engine-Schicht lautet ein berühmtes Diagramm wie folgt:

In der Speicher-Engine-Schicht gibt es auch Caches und Protokolle sowie das Finale Daten werden auf der Festplatte abgelegt.

Der Cache der Speicher-Engine-Schicht wird ebenfalls zur Verbesserung der Leistung verwendet, unterscheidet sich jedoch vom Cache der Datenbank-Dienstschicht. Der Cache der Datenbank-Dienstschicht ist ein Abfrage-Cache, während der Cache der Die Datenbank-Engine-Schicht speichert sowohl Lese- als auch Schreibvorgänge im Cache. Der Cache der Datenbankdienstschicht basiert auf der Abfragelogik, während der Cache der Datenbank-Engine auf Datenseiten basiert, die als physisch bezeichnet werden können.

Selbst wenn die Daten nur in den Cache der Datenbank-Engine-Schicht geschrieben werden, führt dies natürlich dazu, dass die Cache-Seite und die Seite auf der Festplatte für die Datenbank-Service-Schicht, auch wenn sie beibehalten wurden, beschädigt werden Dateninkonsistenz. Diese Inkonsistenz wird durch das Protokoll der Datenbank-Engine-Schicht sichergestellt, um die Integrität sicherzustellen.

Die Protokolle der Datenbank-Engine-Schicht unterscheiden sich also von denen der Datenbank-Service-Schicht. Die Protokolle der Service-Schicht zeichnen die Änderungslogik einzeln auf, während die Protokolle der Engine-Schicht die physischen Unterschiede zwischen ihnen aufzeichnen Cache-Seiten und Datenseiten.

2. Datenbank-Workflow

Beim Empfang einer Abfrage funktionieren die verschiedenen Komponenten in der MySQL-Architektur wie folgt:

Der Client richtet sich ein eine TCP-Verbindung mit der Datenbankdienstschicht. Das Verbindungsverwaltungsmodul stellt die Verbindung her und fordert einen Verbindungsthread an. Wenn im Verbindungspool ein inaktiver Verbindungsthread vorhanden ist, wird dieser dieser Verbindung zugewiesen. Andernfalls wird ein neuer Verbindungsthread erstellt, der diesen Client übernimmt, ohne die maximale Anzahl von Verbindungen zu überschreiten.

Vor dem eigentlichen Betrieb muss das Benutzermodul zur Berechtigungsprüfung aufgerufen werden, um zu überprüfen, ob der Benutzer über Berechtigungen verfügt. Nach der Übergabe wird der Dienst bereitgestellt und der Verbindungsthread beginnt, die SQL-Anweisung vom Client zu empfangen und zu verarbeiten.

Nachdem der Verbindungsthread die SQL-Anweisung empfangen hat, übergibt er die Anweisung zur Syntaxanalyse und semantischen Analyse an das SQL-Anweisungs-Parsing-Modul.

Wenn es sich um eine Abfrageanweisung handelt, können Sie zunächst prüfen, ob Ergebnisse im Abfragecache vorhanden sind. Wenn Ergebnisse vorhanden sind, können diese direkt an den Client zurückgegeben werden.

Wenn im Abfragecache keine Ergebnisse vorhanden sind, müssen Sie die Datenbank-Engine-Ebene tatsächlich abfragen, damit sie zur Abfrageoptimierung an den SQL-Optimierer gesendet wird. Wenn es sich um eine Tabellenänderung handelt, wird sie zur Verarbeitung an die Verarbeitungsmodule Einfügen, Aktualisieren, Löschen, Erstellen und Ändern übergeben.

Der nächste Schritt besteht darin, die Datenbank-Engine-Schicht anzufordern, die Tabelle zu öffnen und bei Bedarf die entsprechende Sperre zu erhalten.

Der nächste Verarbeitungsprozess geht an die Datenbank-Engine-Ebene, wie z. B. InnoDB.

Auf der Ebene der Datenbank-Engine müssen Sie zunächst abfragen, ob entsprechende Daten auf der Cache-Seite vorhanden sind. Wenn nicht, müssen diese direkt von der Festplatte gelesen werden.

Wenn die entsprechenden Daten auf der Festplatte gefunden werden, werden sie in den Cache geladen, wodurch nachfolgende Abfragen effizienter werden. Aufgrund des begrenzten Speichers werden häufig flexible LRU-Tabellen zur Verwaltung von Cache-Seiten verwendet, um die Cache-Zuverlässigkeit sicherzustellen. Dabei handelt es sich um häufig abgerufene Daten.

Nachdem Sie die Daten erhalten haben, geben Sie sie an den Client zurück, schließen Sie die Verbindung, geben Sie den Verbindungsthread frei und der Prozess endet.

3. Prinzip des Datenbankindex

Was im gesamten Prozess am einfachsten als Engpasspunkt bezeichnet wird, ist das Lesen und Schreiben von Daten, was häufig das sequentielle oder zufällige Lesen und Schreiben der Festplatte bedeutet , und das Lesen und Schreiben von Datenträgern ist tendenziell langsamer.

Was wäre, wenn wir diesen Prozess beschleunigen würden? Ich glaube, jeder hat vermutet, dass es darum geht, einen Index zu erstellen.

Warum kann die Indizierung diesen Prozess beschleunigen?

Ich glaube, jeder hat die Food City besucht. Es gibt dort viele Restaurants. Wenn Sie nicht in Eile sind, keinen Hunger haben und keine Anforderungen an die Suchleistung haben, können Sie sich in der Mall Zeit lassen Stöbern Sie von einem Restaurant zum anderen und finden Sie das Restaurant, in dem Sie essen möchten. Aber wenn Sie hungrig sind oder einen Termin in einem Restaurant vereinbart haben, möchten Sie auf jeden Fall direkt in dieses Restaurant gehen. Zu diesem Zeitpunkt werden Sie häufig auf die Etagenkarte schauen, um schnell den Standort Ihres Zielrestaurants zu finden Wenn Sie es finden, gehen Sie direkt zum Thema. Das spart viel Zeit, das ist die Rolle des Index.

Der Index soll also seinen Standort anhand des Werts schnell finden, sodass schnell darauf zugegriffen werden kann.

Eine weitere Funktion des Index besteht darin, dass Sie einige Urteile fällen können, ohne sich die Daten tatsächlich anzusehen. Wenn es beispielsweise ein bestimmtes Restaurant im Einkaufszentrum gibt, können Sie dies anhand des Index erkennen, ohne tatsächlich dorthin zu gehen Das Einkaufszentrum, und wenn Sie alle Sichuan-Restaurants finden möchten, müssen Sie nur einen Blick auf den Index werfen und müssen nicht von einem Sichuan-Restaurant zum anderen gehen.

Wie funktionieren also Indizes in MySQL?

Die Indexstruktur von MySQL ist häufig ein B+-Baum.

Ein B+-Baum der Ordnung M hat die folgenden Eigenschaften:

1. Die Knoten sind in Indexknoten und Datenknoten unterteilt. Der Indexknoten entspricht dem internen Knoten des B-Baums. Alle Indexknoten bilden einen B-Baum und weisen alle Eigenschaften des B-Baums auf. Im Indexknoten werden Schlüssel und Zeiger gespeichert, es werden keine spezifischen Elemente gespeichert. Der Datenknoten entspricht dem externen Knoten des B-Baums. Der externe Knoten des B-Baums ist leer und wird im B+-Baum zum Speichern realer Datenelemente verwendet. Er enthält den Schlüssel und andere Informationen des Elements kein Hinweis.

2. Der aus dem gesamten Indexknoten bestehende B-Baum wird nur verwendet, um herauszufinden, in welchem ​​externen Knoten sich das Datenelement mit einem bestimmten Schlüssel befindet. Nachdem der Schlüssel im Indexknoten gefunden wurde, ist die Angelegenheit noch nicht abgeschlossen. Sie müssen mit der Suche nach dem Datenknoten fortfahren und dann die Elemente im Datenknoten auslesen oder eine binäre Suche oder einen sequentiellen Scan durchführen, um die tatsächlichen Daten zu finden Elemente.

3. Die Reihenfolge M wird nur verwendet, um den Grad des Indexknotenteils zu steuern. Die Anzahl der Elemente, die jeder Datenknoten enthält, hat nichts mit M zu tun.

4. Es gibt auch eine verknüpfte Liste, die alle Datenknoten aneinanderreiht und auf die nacheinander zugegriffen werden kann.

Diese Definition ist relativ abstrakt, schauen wir uns ein konkretes Beispiel an.

Auf dem Bild können wir sehen, dass es sich um einen B+-Baum 3. Ordnung handelt und ein externer Datenknoten bis zu 5 Elemente enthält. Wenn sich die eingefügten Daten im Datenknoten befinden und keine Aufteilung und Zusammenführung verursachen, ändert sich der aus Indexknoten bestehende B-Baum nicht.

Wenn ein Element 76 in den externen Knoten 71 bis 75 eingefügt wird, führt dies zu einer Aufteilung. 71, 72 und 73 werden zu einem Datenknoten und 74, 75 und 76 werden zu einem Datenknoten. Dies entspricht dem Indexknoten beim Einfügen eines Schlüssels von 74.

Wenn 43 von den externen Knoten 41 bis 43 gelöscht wird, werden 41, 42, 61, 62 und 63 zu einem Knoten zusammengeführt Der Vorgang zum Löschen von Schlüssel 60. .

Da die B+-Baumschichthöhe sehr klein ist, kann sie beispielsweise relativ schnell positioniert werden, wenn wir den Wert 62 finden möchten, wenn festgestellt wird, dass er an der Wurzel größer als 40 ist Wenn der Wert kleiner als 70 ist, greifen wir auf die linke Seite zu. Wenn er größer als 60 ist, greifen wir auf die rechte Seite zu. Besuchen Sie dann die rechte Seite am zweiten Blattknoten. Sie werden 62 finden und es erfolgreich finden.

In MySQLs InnoDB gibt es zwei Arten von B+-Baumindizes, einer wird als Clustered-Index und der andere als Sekundärindex bezeichnet.

Die Blattknoten des Clustered-Index sind Datenknoten, häufig wird der Primärschlüssel als Clustered-Index verwendet. Die Blattknoten des Sekundärindex speichern das KEY-Feld plus den Primärschlüsselwert. Daher ist für den Zugriff auf Daten über einen Sekundärindex ein zweimaliger Zugriff auf den Index erforderlich.

Es gibt auch eine Indexform, die als kombinierter Index oder zusammengesetzter Index bezeichnet wird und mehrere Spalten indizieren kann.

Die Sortierregel dieser Art von Index besteht darin, zuerst die erste Spalte zu vergleichen. Wenn die erste Spalte gleich ist, wird die zweite Spalte verglichen und so weiter.

4. Vor- und Nachteile des Datenbankindex

Der offensichtlichste Vorteil des Datenbankindex besteht darin, I/O zu reduzieren. Im Folgenden werden mehrere Szenarien analysiert.

Für Felder mit =-Bedingungen können Sie den B+-Baum direkt durchsuchen und mit einer sehr geringen Anzahl von Festplattenlesevorgängen (entspricht der Höhe des B+-Baums) die Blattknoten erreichen und dann die Daten direkt lokalisieren . Standort.

Da bei Bereichsfeldern der B+-Baum sortiert ist, kann der Bereich schnell im Baum positioniert werden.

Ähnlich gilt für „Orderby“, „Group By“, „Distinct/Max“, „Min“. Da der B+-Baum sortiert ist, können die Ergebnisse schnell erhalten werden.

Es gibt auch ein häufiges Szenario namens Index, der Daten abdeckt. Beispielsweise werden zwei Felder A und B als Bedingungsfelder verwendet, und A = a UND B = b werden häufig angezeigt. Bei gleichzeitiger Auswahl von C und D wird häufig ein gemeinsamer Index (A, B) erstellt, der a ist Sekundärindex, also bei der Suche, Die entsprechenden Blattknoten und Datensätze können schnell über den B+-Baum des Sekundärindex gefunden werden, aber einige der Datensätze enthalten IDs des Clustered-Index, sodass Sie den B+-Baum des Clustered-Index durchsuchen müssen einmal, um die tatsächlichen Datensätze in der Tabelle zu finden, und dann Lesen Sie im Datensatz C und D. Wenn der gemeinsame Index beim Erstellen des gemeinsamen Index (A, B, C, D) lautet, befinden sich alle Daten im B+-Baum des Sekundärindex und können direkt zurückgegeben werden, wodurch der Suchvorgang im Baum reduziert wird.

Natürlich muss die Indexierung ihren Preis haben, es gibt kein kostenloses Mittagessen auf der Welt.

Die meisten Vorteile von Indizes liegen in der Verbesserung der Leseeffizienz, während der Preis von Indizes in der Verringerung der Schreibeffizienz liegt.

Das Einfügen und Ändern von Daten kann zu Indexänderungen führen.

Beim Einfügen wird häufig ein Clustered-Index auf dem Primärschlüssel erstellt. Daher ist es am besten, die automatische Inkrementierung für den Primärschlüssel zu verwenden, damit die eingefügten Daten immer am Ende stehen und sequentiell sind effizienter. Verwenden Sie keine UUIDs für Primärschlüssel. Dies führt zu zufälligen Schreibvorgängen und schlechter Effizienz. Verwenden Sie keine geschäftsbezogenen Primärschlüssel, denn geschäftsbezogen bedeutet, dass sie aktualisiert werden und gelöscht und erneut eingefügt werden müssen, was zu einer schlechten Effizienz führt.

Anhand der obigen Einführung in das Prinzip des B+-Baums können wir sehen, dass die Kosten für die Aufteilung im B+-Baum immer noch relativ hoch sind und die Aufteilung häufig während des Einfügevorgangs erfolgt.

Das Ändern von Daten entspricht im Wesentlichen dem Löschen und erneuten Einfügen, und die Kosten sind relativ hoch.

Sekundäre Indizes für einige Zeichenfolgenspalten verursachen häufig zufälliges Schreiben und Lesen und erhöhen den E/A-Druck.

5. Interpretieren Sie die Prinzipien hinter den Datenbank-Militärvorschriften

Wenn wir die Prinzipien dieser beiden Indizes verstehen, können wir erklären, warum viele sogenannte Datenbank-Militärvorschriften so aussehen. Lassen Sie uns sie unten einzeln erklären.

Unter welchen Umständen sollte ein kombinierter Index anstelle eines separaten Index verwendet werden?

Angenommen, es gibt eine bedingte Anweisung A=a UND B=b. Wenn A und B zwei separate Indizes sind, funktioniert nur ein Index unter der UND-Bedingung. und wenn eine Kombination verwendet wird, muss Index (A, B) nur einen Baum durchlaufen, was die Effizienz erheblich erhöht. Für A=a ODER B=b funktioniert der kombinierte Index jedoch aufgrund der ODER-Beziehung nicht, sodass ein separater Index verwendet werden kann. Zu diesem Zeitpunkt können die beiden Indizes gleichzeitig funktionieren.

Warum sollte der Index differenziert werden? Im kombinierten Index sollte der differenzierte Index an erster Stelle stehen?

Wenn es keine Unterscheidung gibt, z. B. anhand des Geschlechts, entspricht dies der Aufteilung der gesamten großen Tabelle in zwei Teile. Um nach Daten zu suchen, muss immer noch die Hälfte der Tabelle durchsucht werden, wodurch der Index bedeutungslos wird.

Wenn es einen zusammengesetzten Index gibt, benötige ich dann noch einen einspaltigen Index?

Wenn der kombinierte Index (A, B) ist, kann dieser kombinierte Index für die Bedingung A=a verwendet werden, da der kombinierte Index zuerst nach der ersten Spalte sortiert wird, sodass keine Notwendigkeit besteht Erstellen Sie für A einen separaten Index, aber für B = b ist dies nicht sinnvoll, da die zweite Spalte nur dann verglichen wird, wenn die erste Spalte gleich ist, sodass die zweite Spalte gleich ist und auf verschiedene Knoten verteilt werden kann Weg Schnelle Positionierung.

Ist es umso besser, je mehr Indizes vorhanden sind?

Natürlich nicht, das Hinzufügen von Indizes verringert nicht nur die Effizienz des Einfügens und Änderns, sondern führt auch zu einer Verwirrung des Optimierers Um den richtigen Abfragepfad zu finden, wird ein langsamer Index gewählt.

Warum automatisch inkrementierende Primärschlüssel verwenden?

Da String-Primärschlüssel und zufällige Primärschlüssel dazu führen, dass Daten zufällig eingefügt werden, was ineffizient ist, sollten Primärschlüssel seltener aktualisiert werden, um B+-Bäume und häufige Zusammenführungen und Aufteilungen zu vermeiden.

Warum versuchen Sie, NULL nicht zu verwenden?

NULL ist in einem B+-Baum schwieriger zu handhaben und erfordert oft eine spezielle Logik für die Verarbeitung, was wiederum die Effizienz verringert.

Warum nicht Indizes für häufig aktualisierte Felder erstellen?

Das Aktualisieren eines Felds bedeutet, dass auch der entsprechende Index aktualisiert werden muss. Beim Aktualisieren handelt es sich ursprünglich um eine bestimmte Datenstruktur, die im Voraus in der Schreibphase erstellt wurde, was die Lesephase effizienter macht . Hoher Weg, aber wenn ein Feld mehr geschrieben und weniger gelesen wird, wird die Verwendung eines Index nicht empfohlen.

Warum nicht Funktionen in Abfragebedingungen verwenden?

Zum Beispiel wird der Index für die Bedingung ID+1=10 generiert, wenn er im Voraus geschrieben wird. Während der Abfragephase ist der Index für Operationen wie ID+1 nicht geeignet Zuerst alle Indizes hinzufügen und vergleichen. Da dies zu teuer ist, sollte ID=10-1 verwendet werden.

Warum nicht negative Abfragebedingungen wie NOT verwenden?

Sie können sich vorstellen, dass der Basisknoten für einen B+-Baum 40 ist. Wenn Ihre Bedingung gleich 20 ist, gehen Sie zur Überprüfung nach links. Wenn Ihre Bedingung gleich 50 ist, gehen Sie zur Überprüfung nach rechts . Aber Ihr Zustand: Wenn er nicht gleich 66 ist, was soll ich mit dem Index machen? Man weiß es erst, wenn man alles durchgeht.

Warum beginnen Fuzzy-Abfragen nicht mit Platzhalterzeichen?

Wenn bei einem B+-Baum die Wurzel das Zeichen def ist und das Platzhalterzeichen hinten steht, wie zum Beispiel abc%, dann sollte die linke Seite durchsucht werden, wie zum Beispiel efg%, sollte die rechte Seite durchsucht werden , und wenn das Platzhalterzeichen am Anfang steht, %abc, dann wissen Sie nicht, auf welche Seite Sie gehen sollen, es ist besser, sie alle zu scannen.

Warum müssen wir OR in IN ändern oder Union verwenden?

Bei der Optimierung von ODER-Abfragebedingungen ist es oft schwierig, den besten Pfad zu finden, insbesondere wenn es viele ODER-Bedingungen gibt. Für dasselbe Feld ist es besser, IN zu verwenden. Die Bedingungen werden sortiert und verarbeitet einheitlich durch binäre Suche. Für verschiedene Felder ermöglicht die Verwendung von Union, dass jede Unterabfrage einen Index verwendet.

Warum sollten Datentypen so klein wie möglich sein? Für lange Zeichentypen werden häufig Ganzzahltypen anstelle von Zeichentypen verwendet.

Da die Datenbank in Seiten gespeichert ist, ist die Größe jeder Seite gleich. Wenn der Datentyp größer ist, ist die Anzahl der Seiten größer, die auf jeder Seite platzierten Daten werden kleiner und die Die Höhe des Baums ist relativ hoch, sodass die Anzahl der zum Lesen der Suchdaten erforderlichen E/As größer ist und die Knoten beim Einfügen leicht geteilt werden, was die Effizienz verringert. Der Grund für die Verwendung von Ganzzahlen anstelle von Zeichentypen liegt darin, dass Ganzzahlen für die Indizierung effizienter sind, beispielsweise für IP-Adressen. Wenn es lange Zeichentypen gibt, die mithilfe eines Index abgefragt werden müssen, können Sie in Betracht ziehen, das Präfix des Felds anstelle des gesamten Felds zu indizieren, um den Index nicht zu groß zu machen.

6. Methodik zur Abfrageoptimierung

Um die SQL-Anweisungen zu finden, die optimiert werden müssen, müssen Sie zunächst problematische SQL-Anweisungen sammeln.

Die MySQL-Datenbank bietet eine langsame SQL-Protokollfunktion. Über den Parameter slow_query_log können Sie eine Liste von SQL-Angeboten erhalten, deren Ausführungszeit einen bestimmten Schwellenwert überschreitet.

SQL-Anweisungen, die keine Indizes verwenden, können über den Parameter long_queries_not_using_indexes aktiviert werden.

min_examined_row_limit, nur SQL-Anweisungen mit einer Anzahl gescannter Datensätze, die diesen Wert überschreitet, werden im langsamen SQL-Protokoll aufgezeichnet.

Suchen Sie die problematische Aussage. Der nächste Schritt besteht darin, den SQL-Ausführungsplan über EXPLAINSQL abzurufen. Sie können einen Index erstellen, um die Ausführungseffizienz zu optimieren. Ob zu viele Scandatensätze vorhanden sind. Ob die Sperre zu lange gehalten wird oder ob ein Sperrkonflikt vorliegt. Ob die Anzahl der zurückgegebenen Datensätze groß ist.

Als nächstes kann eine maßgeschneiderte Optimierung durchgeführt werden. Für Felder, die an Filterbedingungen beteiligt sind, die nicht vom Index abgedeckt werden, erstellen Sie Indizes für Felder mit größerer Unterscheidung. Wenn mehrere Felder beteiligt sind, versuchen Sie, einen gemeinsamen Index zu erstellen.

Die Anzahl der gescannten Datensätze ist sehr groß, aber die Anzahl der zurückgegebenen Datensätze ist gering und die Unterscheidungsfähigkeit ist schlecht. Bewerten Sie die in der SQL-Anweisung beteiligten Felder neu und wählen Sie mehrere Felder mit hoher Unterscheidungsfähigkeit zum Erstellen aus ein Index.

Die Anzahl der gescannten Datensätze ist sehr groß und die Anzahl der zurückgegebenen Datensätze ist ebenfalls sehr groß. Fügen Sie die SQL-Filterbedingung

schema_redundant_indexes hinzu, um zu sehen, welche redundanten Indizes vorhanden sind es gibt.

Wenn mehrere Indizes Felder in derselben Reihenfolge umfassen, können Sie einen gemeinsamen Index schema_unused_indexes bilden, um zu sehen, welche Indizes nie verwendet werden.

7. Prinzip der Lese-Schreib-Trennung

Datenbanken neigen dazu, weniger zu schreiben und mehr zu lesen, daher besteht der erste Schritt zur Leistungsoptimierung darin, Lesen und Schreiben zu trennen.

Die Master-Slave-Replikation wird basierend auf dem Protokoll der Serviceschicht auf dem Master-Knoten implementiert, und auf dem Slave-Knoten gibt es einen E/A-Thread, um dieses Protokoll zu lesen und dann Schreiben Sie es lokal. Ein anderer Thread liest aus dem lokalen Protokoll und führt es dann auf dem Slave-Knoten erneut aus.

Das Bild zeigt das Flussdiagramm der asynchronen Master-Slave-Replikation. Nachdem die Master-Instanz in die Engine geschrieben hat, gibt sie Erfolg zurück, sendet dann das Ereignis an die Slave-Instanz und führt es auf der Slave-Instanz aus. Diese Synchronisierungsmethode ist schneller, aber wenn der Master auflegt und keine Replikation erfolgt, kann es zu Datenverlustproblemen kommen.

Die synchrone Datenbankreplikation ist auch anders. Nach dem Löschen des Slave-Knotens wird dadurch natürlich die Leistung verringert Technologien wie die parallele Replikation verbessern die Leistung.

Mit der Master-Slave-Replikation kann die Lese-/Schreib-Trennungsstrategie auf der Datenbank-DAO-Ebene festgelegt werden, und dies kann auch über Datenbank-Middleware erfolgen.

Tatsächlich haben Datenbankprotokolle viele andere Verwendungszwecke, z. B. die Verwendung von Canal (Open-Source-Projekt von Alibaba: inkrementelles Abonnement und Verbrauch basierend auf der MySQL-Datenbank Binlog), um das Binlog der Datenbank zu abonnieren, das verwendet werden kann Aktualisieren Sie den Cache usw.