Zusammenfassung der Mysql Hochleistungsoptimierungsfähigkeiten

Datenbank-Befehlsspezifikation

1. Alle Datenbankobjektnamen müssen Kleinbuchstaben enthalten und durch Unterstriche getrennt sein.
2. In allen Datenbankobjektnamen ist die Verwendung von MySQL-reservierten Schlüsselwörtern verboten (wenn der Tabellenname eine Schlüsselwortabfrage enthält, muss diese in einfache Anführungszeichen gesetzt werden).
3. Die Namen von Datenbankobjekten sollten selbsterklärend sein und 32 Zeichen nicht überschreiten.
4. Temporäre Datenbanktabellen müssen mit dem Präfix „tmp_“ und dem Suffix „das Datum“ versehen sein, und Sicherungstabellen müssen mit dem Präfix „bak_“ und dem Suffix „das Datum (Zeitstempel)“ versehen sein.
5. Alle Spalten, die dieselben Daten speichern, müssen denselben Namen und Typ haben (werden im Allgemeinen als verknüpfte Spalten verwendet. Wenn die verknüpften Spaltentypen während der Abfrage inkonsistent sind, wird automatisch eine implizite Datentypkonvertierung durchgeführt, was dazu führt, dass der Index für die Spalte fehlschlägt und die Abfrageeffizienz verringert wird).

Grundlegende Datenbankdesignspezifikationen

1. Alle Tabellen müssen die Innodb-Speicher-Engine verwenden. Wenn keine besonderen Anforderungen bestehen (d. h. Funktionen, die Innodb nicht erfüllen kann, wie z. B. Spaltenspeicher, Speicherplatzdaten usw.), müssen alle Tabellen die Innodb-Speicher-Engine verwenden (vor MySQL 5.5 wird standardmäßig Myisam verwendet, nach 5.6 standardmäßig Innodb).
Innodb unterstützt Transaktionen, Zeilensperren, bessere Wiederherstellbarkeit und bessere Leistung bei hoher Parallelität.

2. Der Zeichensatz der Datenbank und der Tabelle wird vereinheitlicht und verwendet UTF8
Bessere Kompatibilität. Ein einheitlicher Zeichensatz kann durch die Zeichensatzkonvertierung verursachte verstümmelte Zeichen vermeiden. Unterschiedliche Zeichensätze müssen vor dem Vergleich konvertiert werden, was zu Indexfehlern führt. Wenn Emoji-Ausdrücke in der Datenbank gespeichert werden müssen, muss der Zeichensatz den Zeichensatz utf8mb4 verwenden.

3. Alle Tabellen und Felder müssen kommentiert werden. Verwenden Sie die Kommentarklausel, um Tabellen und Spalten Kommentare hinzuzufügen und das Datenwörterbuch von Anfang an zu pflegen

4. Versuchen Sie, die Datengröße in einer einzelnen Tabelle zu kontrollieren. Es wird empfohlen, sie auf 5 Millionen zu begrenzen.
5 Millionen sind nicht die Grenze der MySQL-Datenbank. Wenn die Zahl zu groß ist, verursacht dies große Probleme beim Ändern der Tabellenstruktur, beim Sichern und bei der Wiederherstellung.

Die Datenmenge kann durch die Archivierung historischer Daten (angewendet auf Protokolldaten), Unterbibliotheken und Untertabellen (angewendet auf Geschäftsdaten) usw. gesteuert werden.

5. Verwenden Sie MySQL-Partitionstabellen mit Vorsicht. Partitionstabellen werden physisch durch mehrere Dateien dargestellt, logisch jedoch als eine Tabelle.
Wählen Sie Partitionsschlüssel sorgfältig aus, da partitionsübergreifende Abfragen möglicherweise weniger effizient sind.
Für die Verwaltung großer Datenmengen empfiehlt sich die Verwendung einer physischen Partitionierung.

6. Versuchen Sie, heiße und kalte Daten zu trennen und die Breite der Tabelle zu reduzieren
MySQL begrenzt jede Tabelle auf maximal 4096 Spalten und die Größe jeder Datenzeile darf 65535 Bytes nicht überschreiten.
Reduzieren Sie die Festplatten-E/A, um die Trefferquote des Speichercaches für Hot Data sicherzustellen (je breiter die Tabelle, desto mehr Speicher wird beim Laden der Tabelle in den Speicherpufferpool belegt und desto mehr E/A wird verbraucht).

Nutzen Sie den Cache effektiver, um das Lesen nutzloser „Kaltdaten“ zu vermeiden.

Fügen Sie häufig verwendete Spalten in eine Tabelle ein (um weitere Verknüpfungsvorgänge zu vermeiden).

7. Es ist verboten, reservierte Felder in der Tabelle zu erstellen. Bei der Benennung reservierter Felder ist es schwierig, die Namen klar und aussagekräftig zu gestalten. Das reservierte Feld kann den gespeicherten Datentyp nicht bestätigen, daher kann der entsprechende Typ nicht ausgewählt werden. Änderungen an reservierten Feldtypen sperren die Tabelle.

8. Es ist verboten, große Binärdaten wie Bilder und Dateien in der Datenbank zu speichern. Normalerweise sind die Dateien sehr groß, was dazu führt, dass das Datenvolumen in kurzer Zeit schnell anwächst. Wenn die Datenbank die Datenbank liest, führt sie normalerweise eine große Anzahl zufälliger IO-Operationen aus. Wenn die Datei groß ist, ist die IO-Operation sehr zeitaufwändig.

Normalerweise auf einem Dateiserver gespeichert, speichert die Datenbank nur Dateiadressinformationen

9. Führen Sie keine Datenbank-Stresstests online durch
10. Es ist verboten, von der Entwicklungsumgebung und der Testumgebung aus eine direkte Verbindung zur Datenbank der Produktionsumgebung herzustellen

Spezifikationen für den Datenbankfeldentwurf

1. Priorisieren Sie den kleinsten Datentyp, der den Speicherbedarf erfüllt

Grund:

Je größer das Spaltenfeld, desto mehr Platz wird zum Erstellen des Indexes benötigt. Je weniger Indexknoten auf einer Seite gespeichert werden können, desto mehr IO-Zeiten sind für die Durchquerung erforderlich und desto schlechter ist die Index-Performance.

Verfahren:

Konvertieren Sie eine Zeichenfolge zur Speicherung in einen digitalen Typ, z. B. die Konvertierung einer IP-Adresse in eine Ganzzahl
MySQL bietet zwei Methoden zum Umgang mit IP-Adressen

inet_aton konvertiert IP in vorzeichenlose Ganzzahlen (4-8 Bit)
inet_ntoa konvertiert die ganzzahlige IP-Adresse in eine Adresse. Verwenden Sie vor dem Einfügen von Daten inet_aton, um die IP-Adresse in eine Ganzzahl umzuwandeln und so Platz zu sparen. Verwenden Sie beim Anzeigen von Daten inet_ntoa, um die ganzzahlige IP-Adresse in eine Adresse für die Anzeige umzuwandeln.

Für nicht negative Daten (wie Auto-Increment-ID, Integer-IP) sollten vorzeichenlose Integer zur Speicherung verwendet werden:

Nicht signierte Daten können doppelt so viel Speicherplatz beanspruchen wie signierte Daten.

SIGNIERT INT -2147483648~2147483647
UNSIGNED INT 0~4294967295
Das N in VARCHAR(N) stellt die Anzahl der Zeichen dar, nicht die Anzahl der Bytes. Wenn 255 chinesische Zeichen in UTF8 gespeichert werden, ergibt Varchar(255) = 765 Bytes. * Eine zu große Länge verbraucht mehr Speicher.

2. Vermeiden Sie die Verwendung der Datentypen TEXT und BLOB. Der gängigste TEXT-Typ kann 64 KB Daten speichern.

Es wird empfohlen, BLOB- oder TEXT-Spalten in separate Erweiterungstabellen aufzuteilen.
Temporäre MySQL-Speichertabellen unterstützen keine großen Datentypen wie TEXT und BLOB. Wenn die Abfrage solche Daten enthält, können temporäre Speichertabellen nicht zum Sortieren und für andere Vorgänge verwendet werden. Stattdessen müssen temporäre Festplattentabellen verwendet werden.

Darüber hinaus muss MySQL für diese Art von Daten noch eine zweite Abfrage durchführen, wodurch die SQL-Leistung erheblich beeinträchtigt wird. Dies bedeutet jedoch nicht, dass solche Datentypen nicht verwendet werden können.

Wenn Sie es verwenden müssen, wird empfohlen, die BLOB- oder TEXT-Spalte in eine separate Erweiterungstabelle zu trennen. Verwenden Sie bei der Abfrage nicht select *, sondern rufen Sie nur die erforderlichen Spalten ab. Fragen Sie die TEXT-Spalte nicht ab, wenn die Daten in der Spalte nicht benötigt werden.

TEXT- oder BLOB-Typen können nur Präfixindizes verwenden, da MySQL eine Begrenzung für die Länge von Indexfeldern hat. Daher können TEXT-Typen nur Präfixindizes verwenden und TEXT-Spalten können keine Standardwerte haben.

3. Vermeiden Sie die Verwendung von ENUM-Typen

Um einen ENUM-Wert zu ändern, müssen Sie die ALTER-Anweisung verwenden

Die ORDER BY-Operation vom Typ ENUM ist ineffizient und erfordert zusätzliche Operationen

Es ist verboten, numerische Werte als ENUM-Aufzählungswerte zu verwenden

4. Definieren Sie alle Spalten, wann immer möglich, als NOT NULL

Grund:

Die Indizierung von NULL-Spalten erfordert zusätzlichen Speicherplatz, sodass mehr Platz für Vergleiche und Berechnungen verwendet wird. NULL-Werte müssen speziell behandelt werden.

5. Verwenden Sie den Typ TIMESTAMP (4 Bytes) oder DATETIME (8 Bytes), um die Zeit zu speichern

TIMESTAMP speichert den Zeitbereich 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07
TIMESTAMP belegt 4 Bytes, genauso wie INT, ist aber besser lesbar als INT. Werte außerhalb des TIMESTAMP-Wertebereichs werden mit dem Typ DATETIME gespeichert.

Zum Speichern von Datumsdaten werden häufig Zeichenfolgen verwendet (falsche Vorgehensweise)

Nachteil 1: Datumsfunktionen können nicht für Berechnungen und Vergleiche verwendet werden Nachteil 2: Die Verwendung von Zeichenfolgen zum Speichern von Daten nimmt mehr Platz in Anspruch

6. Finanzbezogene Gelddaten müssen den Dezimaltyp verwenden

Ungenaue Gleitkommazahlen: float, double
Genauigkeit Gleitkomma: Dezimal
Der Typ „Decimal“ ist eine präzise Gleitkommazahl, die bei Berechnungen nicht an Genauigkeit verliert. Der belegte Speicherplatz wird durch die definierte Breite bestimmt. Alle 4 Bytes können 9 Ziffern speichern, und der Dezimalpunkt belegt ein Byte. Er kann verwendet werden, um ganzzahlige Daten zu speichern, die größer als Bigint sind.

Spezifikationen für den Indexentwurf

1. Begrenzen Sie die Anzahl der Indizes für jede Tabelle. Es wird empfohlen, dass eine einzelne Tabelle nicht mehr als 5 Indizes hat, aber je mehr, desto besser! Indizes können die Effizienz steigern, aber auch verringern.

Indizes können die Abfrageeffizienz steigern, sie können jedoch auch die Effizienz von Einfügungen und Aktualisierungen und in manchen Fällen sogar die Abfrageeffizienz verringern.

Denn wenn der MySQL-Optimierer entscheidet, wie eine Abfrage optimiert werden soll, wertet er jeden verfügbaren Index anhand vereinheitlichter Informationen aus, um den besten Ausführungsplan zu generieren. Wenn viele Indizes gleichzeitig für Abfragen verwendet werden können, erhöht dies die Zeit, die der MySQL-Optimierer zum Generieren eines Ausführungsplans benötigt, und verringert auch die Abfrageleistung.

2. Erstellen Sie nicht für jede Spalte in der Tabelle einen separaten Index
Vor Version 5.6 konnte eine SQL-Anweisung nur einen Index in einer Tabelle verwenden. Nach Version 5.6 gibt es zwar eine Optimierungsmethode zum Zusammenführen von Indizes, diese ist jedoch noch lange nicht so gut wie die Abfragemethode mit einem gemeinsamen Index.

3. Jede Innodb-Tabelle muss einen Primärschlüssel haben
Innodb ist eine indexorganisierte Tabelle: Die logische Reihenfolge, in der Daten gespeichert werden, entspricht der Reihenfolge, in der sie indiziert werden. Jede Tabelle kann mehrere Indizes haben, aber die Tabelle kann nur eine Speicherreihenfolge haben.

Innodb organisiert Tabellen in der Reihenfolge der Primärschlüsselindizes.

Verwenden Sie keine häufig aktualisierten Spalten als Primärschlüssel und keine mehrspaltigen Primärschlüssel (entspricht gemeinsamen Indizes).
Verwenden Sie keine UUID-, MD5-, HASH- oder String-Spalten als Primärschlüssel (das sequentielle Wachstum der Daten kann nicht garantiert werden).
Es wird empfohlen, einen Auto-Increment-ID-Wert als Primärschlüssel zu verwenden

Allgemeine Empfehlungen für Indexspalten

Spalten, die in der WHERE-Klausel von SELECT-, UPDATE- und DELETE-Anweisungen vorkommen. Felder, die in ORDER BY, GROUP BY und DISTINCT enthalten sind. Erstellen Sie keinen Index für alle Spalten, die den Feldern in 1 und 2 entsprechen. Normalerweise ist es besser, einen gemeinsamen Index für die Felder in 1 und 2 zu erstellen. Zusammengehörige Spalten von Multi-Table-Joins

So wählen Sie die Reihenfolge der Indexspalten

Der Zweck der Indexerstellung besteht darin, den Index zum Suchen nach Daten zu verwenden, zufällige E/A zu reduzieren und die Abfrageleistung zu erhöhen. Je weniger Daten der Index herausfiltern kann, desto weniger Daten werden von der Festplatte gelesen.

Die diskriminativste Spalte wird auf der linken Seite des gemeinsamen Index platziert (Diskriminativität = Anzahl der unterschiedlichen Werte in der Spalte / Gesamtzahl der Zeilen in der Spalte).
Versuchen Sie, Spalten mit kleineren Feldlängen auf der linken Seite des gemeinsamen Index zu platzieren (denn je kleiner die Feldlänge, desto mehr Daten können auf einer Seite gespeichert werden und desto besser ist die IO-Leistung).
Platzieren Sie die am häufigsten verwendeten Spalten auf der linken Seite des gemeinsamen Index (auf diese Weise können Sie weniger Indizes erstellen).

Vermeiden Sie die Erstellung redundanter und doppelter Indizes (erhöht die Zeit, die der Abfrageoptimierer zum Generieren eines Ausführungsplans benötigt)

Beispiele für doppelte Indizes: Primärschlüssel (ID), Index (ID), eindeutiger Index (ID)
Beispiele für redundante Indizes: index(a,b,c), index(a,b), index(a)

Erwägen Sie bei häufigen Abfragen zunächst die Verwendung von abdeckenden Indizes.

Überdeckender Index: Ein Index, der alle Abfragefelder enthält (Felder, die in „where“, „select“, „ordery by“ und „group by“ enthalten sind). Vorteile eines überdeckenden Index:

Vermeiden Sie eine sekundäre Abfrage des Innodb-Tabellenindex

Innodb speichert Daten in der Reihenfolge der gruppierten Indizes. Bei Innodb speichert der Sekundärindex die Primärschlüsselinformationen der Zeile im Blattknoten. Wenn Sie den Sekundärindex zum Abfragen von Daten verwenden, müssen Sie nach dem Finden des entsprechenden Schlüsselwerts eine Sekundärabfrage über den Primärschlüssel durchführen, um die Daten zu erhalten, die wir tatsächlich benötigen.

In einem überdeckenden Index können alle Daten aus dem Schlüsselwert des sekundären Index abgerufen werden, wodurch sekundäre Abfragen des Primärschlüssels vermieden, E/A-Vorgänge reduziert und die Abfrageeffizienz verbessert werden.

Zufällige IO kann in sequentielle IO umgewandelt werden, um die Abfrageeffizienz zu steigern. Da abdeckende Indizes in der Reihenfolge der Schlüsselwerte gespeichert werden, ist die Daten-IO bei IO-intensiven Bereichssuchen viel geringer als beim zufälligen Lesen jeder Zeile von der Festplatte. Daher kann durch die Verwendung abdeckender Indizes während des Zugriffs die zufällige Lese-IO der Festplatte in sequentielle IO für Indexsuchen umgewandelt werden.

Index SET-Spezifikation

Vermeiden Sie die Verwendung von Fremdschlüsseleinschränkungen so weit wie möglich. Die Verwendung von Fremdschlüsseleinschränkungen wird nicht empfohlen, Sie müssen jedoch Indizes für die Verknüpfungsschlüssel zwischen Tabellen erstellen. Fremdschlüssel können verwendet werden, um die referenzielle Integrität von Daten sicherzustellen. Es wird jedoch empfohlen, Fremdschlüssel auf der Geschäftsseite zu implementieren. Dies wirkt sich auf die Schreibvorgänge der übergeordneten und untergeordneten Tabellen aus und verringert dadurch die Leistung.

Datenbank-SQL-Entwicklungsspezifikationen

1. Es wird empfohlen, vorkompilierte Anweisungen für Datenbankoperationen zu verwenden

Vorkompilierte Anweisungen können diese Pläne wiederverwenden, wodurch die für die SQL-Kompilierung erforderliche Zeit reduziert und das durch dynamisches SQL verursachte SQL-Injection-Problem gelöst wird.

Die ausschließliche Übergabe von Parametern ist effizienter als die Übergabe von SQL-Anweisungen.

Um die Verarbeitungseffizienz zu verbessern, kann die gleiche Anweisung einmal analysiert und mehrmals verwendet werden.

2. Vermeiden Sie implizite Konvertierungen von Datentypen

Eine implizite Konvertierung führt zu einem Indexfehler, beispielsweise:

Wählen Sie Name und Telefonnummer des Kunden mit der ID = „111“;

3. Nutzen Sie die vorhandenen Indizes der Tabelle voll aus

Vermeiden Sie die Verwendung von doppelten %-Zeichen in Abfragebedingungen. Zum Beispiel: a like '%123%' (wenn kein % am Anfang, sondern nur ein % am Ende steht, kann der Index der Spalte verwendet werden)

Eine SQL-Anweisung kann für eine Bereichsabfrage nur eine Spalte in einem zusammengesetzten Index verwenden. Wenn beispielsweise ein gemeinsamer Index für die Spalten a, b und c vorhanden ist und in der Abfragebedingung eine Bereichsabfrage für Spalte a vorliegt, werden die Indizes für die Spalten b und c nicht verwendet.

Wenn beim Definieren eines gemeinsamen Index Spalte A für die Bereichssuche verwendet werden soll, sollte diese auf der rechten Seite des gemeinsamen Index platziert werden und „Left Join“ oder „Not Existes“ sollte verwendet werden, um die „Not In“-Operation zu optimieren, weil „Not In“ normalerweise auch eine Ungültigkeitserklärung des Indexes verursacht.

4. Beim Entwurf einer Datenbank sollten Sie zukünftige Erweiterungen berücksichtigen

5. Das Programm stellt über verschiedene Konten eine Verbindung zu verschiedenen Datenbanken her und führt datenbankübergreifende Abfragen durch

Lassen Sie Platz für die Datenbankmigration sowie für Unterdatenbanken und Untertabellen, um die Geschäftskopplung zu verringern und Sicherheitsrisiken durch übermäßige Berechtigungen zu vermeiden.

6. Verwenden Sie nicht SELECT *. Sie müssen für die Abfrage SELECT <Feldliste> verwenden.

Grund:

Verbraucht mehr CPU- und IO- sowie Netzwerkbandbreitenressourcen. Die Auswirkungen von Änderungen der Tabellenstruktur lassen sich nicht durch abdeckende Indizes reduzieren.

7. Verwenden Sie keine INSERT-Anweisungen ohne Feldliste

wie:

in Werte einfügen ('a', 'b', 'c');

Sollte verwenden:

in t(c1,c2,c3) Werte einfügen ('a','b','c');

8. Vermeiden Sie die Verwendung von Unterabfragen. Sie können Unterabfragen in Join-Operationen optimieren.

Normalerweise kann die Unterabfrage nur dann zur Optimierung in eine korrelierte Abfrage umgewandelt werden, wenn sich die Unterabfrage in der „in“-Klausel befindet und es sich bei der Unterabfrage um einfaches SQL handelt (ausgenommen Union-, „group by“-, „order by“- und „limit“-Klauseln).

Gründe für eine schlechte Unterabfrageleistung:

Der Ergebnissatz einer Unterabfrage kann keinen Index verwenden. Normalerweise wird der Ergebnissatz einer Unterabfrage in einer temporären Tabelle gespeichert. Unabhängig davon, ob es sich um eine temporäre Tabelle im Speicher oder eine temporäre Tabelle auf der Festplatte handelt, wird es keinen Index geben, sodass die Abfrageleistung bis zu einem gewissen Grad beeinträchtigt wird. Insbesondere bei Unterabfragen, die größere Ergebnismengen zurückgeben, ist die Auswirkung auf die Abfrageleistung größer.

Da Unterabfragen eine große Anzahl temporärer Tabellen ohne Indizes generieren, verbrauchen sie zu viele CPU- und IO-Ressourcen und generieren eine große Anzahl langsamer Abfragen.

9. Vermeiden Sie die Verwendung von JOIN zum Verbinden zu vieler Tabellen

Für MySQL gibt es einen zugehörigen Cache, und die Größe des Cache kann mit dem Parameter join_buffer_size festgelegt werden.

Wenn Sie in MySQL mehrere Tabellen in derselben SQL-Anweisung verknüpfen, wird ein weiterer Assoziationscache zugewiesen. Je mehr Tabellen in einer SQL-Anweisung verknüpft sind, desto mehr Speicher wird belegt.

Wenn im Programm eine große Anzahl von Verknüpfungsvorgängen für mehrere Tabellen verwendet wird und die Join_Buffer_Size nicht angemessen eingestellt ist, führt dies leicht zu einem Überlauf des Serverspeichers, was wiederum die Stabilität der Leistung der Serverdatenbank beeinträchtigt.

Gleichzeitig werden für den Zuordnungsvorgang temporäre Tabellenvorgänge generiert, die die Abfrageeffizienz beeinträchtigen. MySQL erlaubt die Zuordnung von maximal 61 Tabellen und es wird empfohlen, nicht mehr als 5 zu verwenden.

10. Reduzieren Sie die Anzahl der Interaktionen mit der Datenbank

Datenbanken eignen sich besser für die Verarbeitung von Batch-Vorgängen. Die Kombination mehrerer identischer Vorgänge kann die Verarbeitungseffizienz verbessern.

11. Wenn Sie eine oder mehrere Beurteilungen in derselben Spalte vornehmen, verwenden Sie in anstelle von oder

Die Anzahl der In-Werte sollte 500 nicht überschreiten. Der In-Vorgang kann Indizes effektiver nutzen oder in den meisten Fällen nur selten Indizes verwenden.

12. Verwenden Sie order by rand() nicht für die zufällige Sortierung

order by rand() lädt alle Daten, die die Bedingungen in der Tabelle erfüllen, in den Speicher und sortiert dann alle Daten im Speicher nach den zufällig generierten Werten und kann für jede Zeile einen Zufallswert generieren. Wenn der Datensatz, der die Bedingungen erfüllt, sehr groß ist, verbraucht er viele CPU-, IO- und Speicherressourcen.

Es wird empfohlen, im Programm einen Zufallswert abzurufen und dann die Daten aus der Datenbank abzurufen.

13. Funktionskonvertierung und Berechnung von Spalten sind in der WHERE-Klausel verboten

Beim Umwandeln oder Berechnen einer Spalte mittels einer Funktion ist der Index nicht verwendbar.

Nicht empfohlen:

where date(create_time)='20190101'


empfehlen:

where create_time >= '20190101' and create_time < '20190102'

14. Verwenden Sie UNION ALL anstelle von UNION, wenn offensichtlich keine doppelten Werte vorhanden sind

UNION fügt alle Daten der beiden Ergebnismengen in eine temporäre Tabelle ein und führt dann eine Deduplizierung durch.
UNION ALL führt keine Deduplizierung mehr auf dem Ergebnissatz durch

15. Teilen Sie komplexe große SQL-Anweisungen in mehrere kleine SQL-Anweisungen auf

Das große SQL ist logisch komplex und erfordert für die Berechnung viel CPU-Leistung.
In MySQL kann eine SQL-Anweisung nur eine CPU für die Berechnung verwenden.
SQL-Splitting kann die Verarbeitungseffizienz durch parallele Ausführung verbessern

Spezifikation des Datenbankvorgangsverhaltens

Batch-Schreibvorgänge (UPDATE, DELETE, INSERT) von mehr als 1 Million Zeilen müssen in mehreren Batches ausgeführt werden.

1. Große Batch-Operationen können zu erheblichen Master-Slave-Verzögerungen führen

In einer Master-Slave-Umgebung können große Batch-Operationen zu erheblichen Master-Slave-Verzögerungen führen. Die Ausführung großer Batch-Schreibvorgänge dauert im Allgemeinen lange.

Erst wenn die Ausführung in der Masterdatenbank abgeschlossen ist, wird sie in anderen Slavedatenbanken ausgeführt, sodass es zu einer langen Verzögerung zwischen der Masterdatenbank und der Slavedatenbank kommt.

2. Wenn Binlog-Protokolle im Zeilenformat vorliegen, wird eine große Anzahl von Protokollen generiert

Große Batch-Schreibvorgänge erzeugen eine große Anzahl von Protokollen, insbesondere bei binären Daten im Zeilenformat. Da die Änderungen jeder Datenzeile im Zeilenformat aufgezeichnet werden, werden umso mehr Protokolle erzeugt, je mehr Daten wir gleichzeitig ändern, und umso länger dauert das Übertragen und Wiederherstellen der Protokolle. Dies ist auch ein Grund für die Master-Slave-Verzögerung.

3. Vermeiden Sie große Transaktionsvorgänge

Große Datenmengen müssen in einer Transaktion geändert werden, wodurch große Datenmengen in der Tabelle gesperrt werden, was zu zahlreichen Blockierungen führt und die MySQL-Leistung erheblich beeinträchtigt.

Insbesondere eine langfristige Blockierung belegt alle verfügbaren Verbindungen der Datenbank, wodurch andere Anwendungen in der Produktionsumgebung keine Verbindung zur Datenbank herstellen können. Daher ist es wichtig zu beachten, dass große Batch-Schreibvorgänge in Batches ausgeführt werden müssen.

Bei großen Tabellen verwenden Sie pt-online-schema-change, um die Tabellenstruktur zu ändern

Vermeidung von Master-Slave-Verzögerungen durch umfangreiche Tabellenänderungen

Vermeiden Sie das Sperren der Tabelle, wenn Sie Tabellenfelder ändern. Seien Sie vorsichtig, wenn Sie die Datenstruktur einer großen Tabelle ändern, da dies schwerwiegende Tabellensperrvorgänge zur Folge hat, die insbesondere in einer Produktionsumgebung nicht tolerierbar sind.

pt-online-schema-change erstellt zuerst eine neue Tabelle mit derselben Struktur wie die Originaltabelle, ändert die Tabellenstruktur der neuen Tabelle, kopiert dann die Daten der Originaltabelle in die neue Tabelle und fügt der Originaltabelle einige Trigger hinzu.

Kopieren Sie die neu hinzugefügten Daten in der Originaltabelle in die neue Tabelle. Nachdem alle Zeilendaten kopiert wurden, benennen Sie die neue Tabelle als Originaltabelle und löschen Sie die Originaltabelle. Teilen Sie den ursprünglichen DDL-Vorgang in mehrere kleine Stapel auf.

Es ist verboten, dem vom Programm verwendeten Konto Superberechtigungen zu erteilen

Wenn die maximale Anzahl an Verbindungen erreicht ist, wird ein anderer Benutzer mit Superprivilegien ausgeführt.
Das Superprivileg kann nur vom DBA-Konto zur Problembehandlung verwendet werden

Damit das Programm eine Verbindung zum Datenbankkonto herstellen kann, befolgen Sie das Prinzip der geringsten Privilegien

Das vom Programm verwendete Datenbankkonto kann nur unter einer DB verwendet werden. Das vom Programm datenbankübergreifend verwendete Konto darf grundsätzlich keine Drop-Berechtigungen besitzen.