MySQL-Abfrageoptimierung: Eine Tabellenoptimierungslösung für 1 Million Daten

1. Abfragegeschwindigkeit von zwei Abfrage-Engines (myIsam-Engine)

InnoDB speichert nicht die genaue Anzahl der Zeilen in einer Tabelle. Das heißt, wenn select count(*) from table ausgeführt wird, muss InnoDB die gesamte Tabelle durchsuchen, um die Anzahl der Zeilen zu berechnen.

MyISAM liest einfach die Anzahl der gespeicherten Zeilen.

Beachten Sie, dass die Operationen für die beiden Tabellen leicht unterschiedlich sind, wenn die count(*)-Anweisung eine Where-Bedingung enthält. Tabellen vom Typ InnoDB verwenden count(*) oder count(Primärschlüssel) plus die Where-Col-Bedingung. Die Spalte „col“ ist eine andere Spalte als der Primärschlüssel der Tabelle, die über einen eindeutigen Einschränkungsindex verfügt. Dadurch wird die Abfrage sehr schnell. Dadurch werden vollständige Tabellenscans vermieden.

Zusammenfassen:

Wenn in MySQL 3 Millionen Datensätze vorhanden sind (MyISAM-Engine), ist die Ausführungszeit normal, wenn mit count(*) die Gesamtzahl der Datensätze unter der Bedingung (korrektes Festlegen des Index) abgefragt wird. Für häufig gelesene Daten empfehlen wir die Verwendung der myIsam-Engine.

2. MySQL-Paging-Problem mit Millionen von Daten

Während der Entwicklung verwenden wir häufig Paging. Die Kerntechnologie besteht darin, Limits zum Lesen von Daten zu verwenden. Während des Tests der Verwendung von Limits zum Paging werden die folgenden Daten erhalten:

select * aus den Nachrichten sortieren nach ID desc limit 0,10
Es dauerte 0,003 Sekunden select * from news order by id desc limit 10000,10
Es dauerte 0,058 Sekunden, um * aus der Nachrichtenreihenfolge nach ID Desc-Limit 100000,10 auszuwählen 
Es dauerte 0,575 Sekunden, um * aus der Nachrichtenreihenfolge nach ID Desc-Limit 1000000,10 auszuwählen
Es dauerte 7,28 Sekunden

Wir waren überrascht, dass bei großen Datenmengen die Abfragegeschwindigkeit umso langsamer ist, je größer der Paging-Startpunkt ist. Die Abfragegeschwindigkeit für 1 Million oder mehr Datensätze beträgt bereits 7 Sekunden. Diese Zahl können wir nicht akzeptieren!

Verbesserungsplan 1

Wählen Sie * aus den Nachrichten 
wobei ID > (ID aus Nachrichtensortierung nach ID-Abstiegslimit 1000000, 1 auswählen)
Sortieren nach ID absteigend 
Grenze 0,10

Die Abfragezeit beträgt 0,365 Sekunden und die Effizienzverbesserung ist sehr offensichtlich! ! Wie funktioniert es? ? ?

Wir verwenden Bedingungen, um die ID zu filtern. In der Unterabfrage (select id from news order by id desc limit 1000000, 1) fragen wir nur das ID-Feld ab, was im Vergleich zu „select *“ oder „select multiple fields“ viel Abfrageaufwand spart!

Verbesserungsplan 2

Geeignet für Systeme mit durchgehenden IDs, extrem schnell!

Wählen Sie * aus den Nachrichten 
wobei die ID zwischen 1000000 und 1000010 liegt 
Sortieren nach ID absteigend

Es ist nicht für Abfragen mit Bedingungen und diskontinuierlichen IDs geeignet. Sehr schnell!

3. Was bei der Abfrage von MySQL-Bedingungen und Paging-Abfragen mit Millionen von Daten zu beachten ist

In Fortsetzung des vorherigen Abschnitts fügen wir die Abfragebedingungen hinzu:

ID aus News auswählen 
wobei cate = 1
Sortieren nach ID absteigend 
Grenze 500000 ,10 
Abfragezeit 20 Sekunden

Was für eine erschreckende Geschwindigkeit! ! Nutzen Sie die Erkenntnisse aus dem ersten Abschnitt zur Optimierung von:

Wählen Sie * aus den Nachrichten
wobei cate = 1 und id > (ID aus News auswählen, wobei cate = 1 ist, nach ID sortieren, Abstiegslimit 500000,1) 
Sortieren nach ID absteigend 
Grenze 0,10 
Abfragezeit 15 Sekunden

Der Optimierungseffekt ist nicht offensichtlich und der Einfluss der Bedingungen ist immer noch sehr groß! In diesem Fall können wir das Problem der Betriebseffizienz nicht lösen, egal wie sehr wir die SQL-Anweisung optimieren. Ändern Sie dann die Idee: Erstellen Sie eine Indextabelle, um nur die Artikel-ID und die Klassifizierungsinformationen aufzuzeichnen, und trennen Sie das große Feld des Artikelinhalts.

Tabelle news2 [Artikeltabelle Engine Myisam Zeichensatz UTF-8]

id int 11 Primärschlüssel erhöht sich automatisch

cate int 11 Index

Synchronisieren Sie die beiden Tabellen, wenn Sie Daten schreiben. Bei Abfragen können Sie news2 verwenden, um bedingte Abfragen durchzuführen:

Wählen Sie * aus den Nachrichten
wobei cate = 1 und id > (wählen Sie id aus news2, wobei cate = 1 ist, sortieren nach id desc-Limit 500000,1) 
Sortieren nach ID absteigend 
Grenze 0,10

Beachten Sie, dass die Bedingungs-ID > die News2-Tabelle verwendet!

Die Laufzeit beträgt 1,23 Sekunden. Wir können sehen, dass die Laufzeit um fast das 20-fache reduziert wurde! ! Bei einem Datenumfang von ca. 100.000 lässt sich die Abfragezeit bei ca. 0,5 Sekunden halten und nähert sich damit langsam einem für uns tolerierbaren Wert an!

Aber 1 Sekunde ist für den Server immer noch ein inakzeptabler Wert! ! Gibt es eine andere Möglichkeit, es zu optimieren? ? Wir haben eine tolle Variante ausprobiert:

Wenn ich die Speicher-Engine von News2 auf InnoDB ändere, sind die Ergebnisse erstaunlich!

Wählen Sie * aus den Nachrichten
wobei cate = 1 und id > (wählen Sie id aus news2, wobei cate = 1 ist, sortieren nach id desc-Limit 500000,1) 
Sortieren nach ID absteigend 
Grenze 0,10

Es dauert nur 0,2 Sekunden, was wirklich schnell ist.

4. Der Unterschied zwischen der MySQL-Speicher-Engine myIsam und innodb

MySQL verfügt über mehrere Speicher-Engines, MyISAM und InnoDB sind zwei häufig verwendete. Hier sind einige grundlegende Konzepte zu diesen beiden Engines (keine ausführliche Einführung).

Die MyISAM-Speicher-Engine, die auf dem traditionellen ISAM-Typ basiert, unterstützt die Volltextsuche, ist jedoch nicht transaktionssicher und unterstützt keine Fremdschlüssel. Jede MyISAM-Tabelle wird in drei Dateien gespeichert: Die frm-Datei speichert die Tabellendefinition; die Datendatei ist MYD (MYData); und die Indexdatei ist MYI (MYIndex).

InnoDB ist eine Transaktions-Engine, die Rollback, Wiederherstellung nach einem Absturz, gleichzeitige Steuerung mehrerer Versionen, ACID-Transaktionen und Zeilensperren unterstützt (die Zeilensperren von InnoDB-Tabellen sind nicht absolut. Wenn MySQL beim Ausführen einer SQL-Anweisung den zu scannenden Bereich nicht bestimmen kann, sperrt die InnoDB-Tabelle auch die gesamte Tabelle, z. B. die SQL-Anweisung während des ähnlichen Vorgangs) und eine nicht sperrende Lesemethode bereitstellt, die mit dem Oracle-Typ übereinstimmt. InnoDB speichert seine Tabellen und Indizes in einem Tablespace, der mehrere Dateien enthalten kann.

Wesentliche Unterschiede

MyISAM ist nicht transaktionssicher, während InnoDB transaktionssicher ist.

Die Granularität der MyISAM-Sperren erfolgt auf Tabellenebene, während InnoDB Sperren auf Zeilenebene unterstützt.

MyISAM unterstützt die Volltextindizierung, InnoDB nicht.

MyISAM ist relativ einfach und daher effizienter als InnoDB. Kleine Anwendungen können die Verwendung von MyISAM in Betracht ziehen.

MyISAM-Tabellen werden in Form von Dateien gespeichert. Die Verwendung des MyISAM-Speichers bei der plattformübergreifenden Datenübertragung erspart viel Ärger.

InnoDB-Tabellen sind sicherer als MyISAM-Tabellen. Sie können von nicht-transaktionalen Tabellen zu transaktionalen Tabellen wechseln (alter table tablename type=innodb), ohne dass Daten verloren gehen.

Anwendungsszenario

MyISAM verwaltet nicht transaktionale Tabellen. Es bietet Hochgeschwindigkeitsspeicherung und -abruf sowie Volltextsuchfunktionen. Wenn Ihre Anwendung eine große Anzahl von SELECT-Abfragen ausführen muss, ist MyISAM die bessere Wahl.

InnoDB ist für Anwendungen zur Transaktionsverarbeitung konzipiert und verfügt über viele Funktionen, einschließlich ACID-Transaktionsunterstützung. Wenn in Ihrer Anwendung eine große Anzahl von INSERT- oder UPDATE-Operationen ausgeführt werden müssen, sollte InnoDB verwendet werden, um die Leistung gleichzeitiger Operationen mehrerer Benutzer zu verbessern.

Mysql-Speicher-Engine und Index

Die Datenbank muss einen Index haben. Ohne Index wird der Abrufvorgang zu einer sequentiellen Suche, und die zeitliche Komplexität von O(n) ist nahezu unerträglich. Es ist sehr einfach, sich vorzustellen, wie man mit einem B+-Baum eine Tabelle indizieren kann, die nur aus einem einzigen Schlüsselwort besteht, solange das Schlüsselwort im Knoten des Baums gespeichert ist. Wenn ein Datensatz in der Datenbank mehrere Felder enthält, kann ein B+-Baum nur den Primärschlüssel speichern. Wenn ein Nicht-Primärschlüsselfeld abgerufen wird, verliert der Primärschlüsselindex seine Funktion und es wird eine sequentielle Suche. Zu diesem Zeitpunkt sollte ein zweiter Satz Indizes für die zweite abzurufende Spalte erstellt werden. Der Index ist als separate B+-Bäume organisiert. Um das Problem zu lösen, dass mehrere B+-Bäume auf denselben Satz von Tabellendaten zugreifen, gibt es zwei gängige Methoden: eine wird als gruppierter Index und die andere als nicht gruppierter Index (sekundärer Index) bezeichnet. Obwohl beide Bezeichnungen Index lauten, handelt es sich hierbei nicht um einen eigenen Indextyp, sondern um eine Möglichkeit zur Datenspeicherung. Bei der Clustered-Index-Speicherung werden Zeilendaten und Primärschlüssel-B+-Baum zusammen gespeichert, während Sekundärschlüssel-B+-Baum nur Sekundärschlüssel und Primärschlüssel speichert. Primärschlüssel- und Nicht-Primärschlüssel-B+-Baum sind fast zwei Baumtypen. Bei der nicht gruppierten Indexspeicherung speichert der Primärschlüssel-B+-Baum anstelle der Primärschlüssel Zeiger auf die tatsächlichen Datenzeilen in den Blattknoten.

InnoDB verwendet einen Clusterindex, um den Primärschlüssel in einem B+-Baum zu organisieren, und die Zeilendaten werden in den Blattknoten gespeichert. Wenn Sie eine Bedingung wie „where id = 14“ verwenden, um nach dem Primärschlüssel zu suchen, können Sie den entsprechenden Blattknoten gemäß dem B+-Baumabrufalgorithmus finden und dann die Zeilendaten abrufen. Wenn Sie eine bedingte Suche in der Spalte „Name“ durchführen, sind zwei Schritte erforderlich: Der erste Schritt besteht darin, „Name“ im Hilfsindex-B+-Baum abzurufen und dessen Blattknoten zu erreichen, um den entsprechenden Primärschlüssel zu erhalten. Der zweite Schritt besteht darin, mit dem Primärschlüssel einen weiteren B+-Baumsuchvorgang im Primärindex-B+-Baum durchzuführen und schließlich den Blattknoten zu erreichen, um die gesamte Datenzeile zu erhalten.

MyISM verwendet einen nicht gruppierten Index. Die beiden B+-Bäume des nicht gruppierten Index sehen nicht anders aus. Die Struktur der Knoten ist genau gleich, aber der gespeicherte Inhalt ist unterschiedlich. Die Knoten des Primärschlüsselindex-B+-Baums speichern den Primärschlüssel und die Knoten des Sekundärschlüsselindex-B+-Baums speichern den Sekundärschlüssel. Die Tabellendaten werden an einem unabhängigen Ort gespeichert. Die Blattknoten dieser beiden B+-Bäume verwenden eine Adresse, um auf die tatsächlichen Tabellendaten zu verweisen. Für die Tabellendaten gibt es keinen Unterschied zwischen diesen beiden Schlüsseln. Da die Indexbäume unabhängig sind, ist für den Abruf per Sekundärschlüssel kein Zugriff auf den Indexbaum des Primärschlüssels erforderlich.

Um den Unterschied zwischen den beiden Indizes deutlicher zu veranschaulichen, stellen wir uns eine Tabelle vor, in der 4 Datenzeilen gespeichert sind, wie unten gezeigt. „ID“ ist der Primärindex und „Name“ der Sekundärindex. Das Diagramm zeigt deutlich den Unterschied zwischen gruppierten und nicht gruppierten Indizes.

Wir konzentrieren uns auf gruppierte Indizes. Es scheint, dass die Effizienz gruppierter Indizes deutlich geringer ist als die nicht gruppierter Indizes, da jeder Abruf mithilfe von Hilfsindizes zwei B+-Baumsuchen erfordert. Ist das nicht redundant? Was sind die Vorteile von Clustered-Indizes?

1 Da Zeilendaten und Blattknoten zusammen gespeichert werden, werden der Primärschlüssel und die Zeilendaten zusammen in den Speicher geladen. Sobald der Blattknoten gefunden wurde, können die Zeilendaten sofort zurückgegeben werden. Wenn die Daten nach der Primärschlüssel-ID organisiert sind, können sie schneller abgerufen werden.

2 Der Vorteil der Verwendung des Primärschlüssels als „Zeiger“ anstelle des Adresswerts als Zeiger für den Hilfsindex besteht darin, dass der Wartungsaufwand für den Hilfsindex beim Verschieben von Zeilen oder Aufteilen von Datenseiten verringert wird. Die Verwendung des Primärschlüsselwerts als Zeiger führt zwar dazu, dass der Hilfsindex mehr Platz einnimmt, der Vorteil besteht jedoch darin, dass InnoDB den „Zeiger“ im Hilfsindex beim Verschieben von Zeilen nicht aktualisieren muss. Das heißt, die Position der Zeile (in der Implementierung, die später erläutert wird, befindet sich bei 16K Page) ändert sich, wenn die Daten in der Datenbank geändert werden (vorherige Aufteilung der Knoten und Seiten des B+-Baums). Durch die Verwendung eines gruppierten Index kann sichergestellt werden, dass der Hilfsindexbaum nicht betroffen ist, unabhängig davon, wie sich die Knoten des Primärschlüssel-B+-Baums ändern.

Wenn es um Millionen oder mehr Daten geht, ist die Indexleistung von MySQL InnoDB daher sogar noch besser!

5. Einige Erfahrungen in der MySQL-Leistungsoptimierung

a. Optimieren Sie Ihre Abfrage für Abfrage

Auf den meisten MySQL-Servern ist der Abfragecache aktiviert. Dies ist eine der effektivsten Möglichkeiten zur Verbesserung der Leistung und wird von der MySQL-Datenbank-Engine übernommen. Wenn viele identische Abfragen mehrmals ausgeführt werden, werden die Abfrageergebnisse in einen Cache gestellt, sodass nachfolgende identische Abfragen direkt auf die zwischengespeicherten Ergebnisse zugreifen können, ohne die Tabelle bearbeiten zu müssen.

Das Hauptproblem hierbei ist, dass diese Angelegenheit von Programmierern sehr leicht übersehen werden kann. Weil einige unserer Abfrageanweisungen dazu führen, dass MySQL den Cache nicht verwendet.

Schauen Sie sich das folgende Beispiel an:

// Abfrage-Cache ist nicht aktiviert

$r = mysql_query("SELECT Benutzername FROM Benutzer WHERE Anmeldedatum >= CURDATE()");

// Abfrage-Cache aktivieren

$heute = Datum("Jmd");

$r = mysql_query("SELECT Benutzername FROM Benutzer WHERE Anmeldedatum >= '$today'");

Der Unterschied zwischen den beiden obigen SQL-Anweisungen ist CURDATE(). Der MySQL-Abfragecache funktioniert für diese Funktion nicht. Daher aktivieren SQL-Funktionen wie NOW() und RAND() oder andere ähnliche Funktionen kein Abfrage-Caching, da die Rückgabewerte dieser Funktionen unsicher und volatil sind. Sie müssen also lediglich die MySQL-Funktion durch eine Variable ersetzen, um das Caching zu aktivieren.

b. Lernen Sie, EXPLAIN zu verwenden

Mithilfe des Schlüsselworts EXPLAIN können Sie sehen, wie MySQL Ihre SQL-Anweisungen verarbeitet.

wähle ID, Titel, Kategorie aus News, wobei Kategorie = 1

Wenn Sie feststellen, dass die Abfrage langsam ist, können Sie die Abfrage beschleunigen, indem Sie dem Cate-Feld einen Index hinzufügen.

c. Verwenden Sie LIMIT 1, wenn nur eine Datenzeile benötigt wird

Wenn Sie eine Tabelle abfragen und nur ein Datenelement benötigen, verwenden Sie das Limit 1.

d. Indizes richtig verwenden

Indizes dienen nicht unbedingt für Primärschlüssel oder eindeutige Felder. Sollte es in Ihrer Tabelle ein Feld geben, dass Sie häufig zum Suchen, Aufnehmen von Bildern oder Konditionieren nutzen, dann legen Sie hierfür bitte einen Index an.

e. Nicht ORDER BY RAND() verwenden

Eine sehr ineffiziente Zufallsabfrage.

f. Vermeiden Sie SELECT *

Je mehr Daten Sie aus der Datenbank lesen, desto langsamer wird die Abfrage. Wenn Ihr Datenbankserver und Ihr Webserver zwei unabhängige Server sind, erhöht dies außerdem die Belastung der Netzwerkübertragung. Sie müssen sich die gute Angewohnheit aneignen, alles zu nehmen, was Sie brauchen.

g. Verwenden Sie ENUM statt VARCHAR

Der ENUM-Typ ist sehr schnell und kompakt. In Wirklichkeit speichert es einen TINYINT, erscheint aber als Zeichenfolge. Dadurch eignet es sich perfekt zum Erstellen einer Liste mit Optionen.

Wenn Sie ein Feld wie „Geschlecht“, „Land“, „Ethnizität“, „Staat“ oder „Abteilung“ haben, von dem Sie wissen, dass es eine begrenzte Anzahl von Werten haben wird, sollten Sie ENUM statt VARCHAR verwenden.

h. Verwenden von NOT NULL

Sofern es keinen ganz bestimmten Grund für die Verwendung von NULL-Werten gibt, sollten Sie Ihre Spalten immer auf NOT NULL setzen. Dies mag etwas kontrovers erscheinen, lesen Sie bitte weiter.

Fragen Sie sich zunächst, wie sich „Empty“ von „NULL“ unterscheidet (im Fall von INT wären das 0 und NULL)? Wenn Sie der Meinung sind, dass zwischen ihnen kein Unterschied besteht, sollten Sie NULL nicht verwenden. (Wussten Sie, dass in Oracle NULL und Empty dieselbe Zeichenfolge sind?)

Gehen Sie nicht davon aus, dass NULL keinen Platz benötigt. Es erfordert zusätzlichen Platz und Ihr Programm wird bei Vergleichen komplizierter. Das bedeutet natürlich nicht, dass Sie NULL nicht verwenden können. Die Realität ist sehr kompliziert und es gibt immer noch einige Fälle, in denen Sie NULL-Werte verwenden müssen.

Das Folgende ist ein Auszug aus der MySQL-Dokumentation

„NULL-Spalten benötigen zusätzlichen Platz in der Zeile, um aufzuzeichnen, ob ihre Werte NULL sind. Bei MyISAM-Tabellen benötigt jede NULL-Spalte ein zusätzliches Bit, aufgerundet auf das nächste Byte.“

i. Die IP-Adresse wird als UNSIGNED INT gespeichert

Viele Programmierer erstellen ein VARCHAR(15)-Feld, um die String-IP statt der Integer-IP zu speichern. Wenn Sie zur Speicherung eine Ganzzahl verwenden, sind nur 4 Byte erforderlich und Sie können Felder mit fester Länge haben. Darüber hinaus bringt Ihnen dies Vorteile bei Abfragen, insbesondere wenn Sie solche WHERE-Bedingungen verwenden müssen: IP zwischen IP1 und IP2.

Wir müssen UNSIGNED INT verwenden, da die IP-Adresse die gesamte 32-Bit-Ganzzahl ohne Vorzeichen verwendet.

j. Tabellen mit fester Länge sind schneller

Wenn alle Felder einer Tabelle eine „feste Länge“ haben, wird die gesamte Tabelle als „statisch“ oder „feste Länge“ betrachtet. Beispielsweise verfügt die Tabelle nicht über Felder der folgenden Typen: VARCHAR, TEXT, BLOB. Solange Sie eines dieser Felder einschließen, ist die Tabelle keine „statische Tabelle mit fester Länge“ mehr und die MySQL-Engine verarbeitet sie anders.

Tabellen mit fester Länge verbessern die Leistung, weil MySQL schneller sucht. Und da diese festen Längen die Berechnung des Offsets der nächsten Daten erleichtern, erfolgt das Lesen natürlich schnell. Wenn das Feld keine feste Länge hat, muss das Programm jedes Mal, wenn Sie den nächsten Eintrag finden möchten, den Primärschlüssel finden.

Darüber hinaus lassen sich Tabellen mit fester Länge einfacher zwischenspeichern und neu erstellen. Der einzige Nebeneffekt besteht jedoch darin, dass Felder mit fester Länge etwas Speicherplatz verschwenden, da Felder mit fester Länge unabhängig davon, ob Sie ihn verwenden oder nicht, so viel Speicherplatz zuweisen.

k. Vertikale Teilung

„Vertikale Aufteilung“ ist eine Methode zum Aufteilen einer Tabelle in einer Datenbank in mehrere Tabellen nach Spalten, wodurch die Komplexität der Tabelle und die Anzahl der Felder verringert und so der Optimierungszweck erreicht werden kann. Beachten Sie, dass Sie die durch diese getrennten Felder gebildeten Tabellen nicht häufig verbinden sollten. Andernfalls ist die Leistung schlechter als bei nicht getrennten Feldern und sinkt exponentiell.

l. Große DELETE- oder INSERT-Anweisungen aufteilen

Wenn Sie eine große DELETE- oder INSERT-Abfrage auf einer Live-Website ausführen, müssen Sie sehr vorsichtig sein, um zu vermeiden, dass Ihre Operation die gesamte Website zum Absturz bringt. Denn diese beiden Vorgänge sperren die Tabelle. Sobald die Tabelle gesperrt ist, können keine weiteren Vorgänge ausgeführt werden.

Apache wird viele untergeordnete Prozesse oder Threads haben. Daher funktioniert es recht effizient und unser Server möchte nicht zu viele Unterprozesse, Threads und Datenbanklinks haben, die viele Serverressourcen, insbesondere den Speicher, beanspruchen würden.

Wenn Sie Ihre Tabelle für einen bestimmten Zeitraum, z. B. 30 Sekunden, sperren, kann dies bei einer Site mit hohem Datenverkehr aufgrund der in diesen 30 Sekunden angesammelten Zugriffsprozesse/Threads, Datenbanklinks und der Anzahl geöffneter Dateien nicht nur zum Absturz Ihres Webdienstes führen, sondern auch dazu, dass Ihr gesamter Server sofort hängt.

m. Kleinere Spalten sind schneller

Für die meisten Datenbankmodule stellen Festplattenvorgänge wahrscheinlich den größten Engpass dar. Daher kann es in dieser Situation sehr hilfreich sein, Ihre Daten zu komprimieren, da dadurch die Anzahl der Zugriffe auf die Festplatte verringert wird.

n. Wählen Sie die richtige Speicher-Engine

Es gibt zwei Speicher-Engines in MySQL: MyISAM und InnoDB, jede davon hat ihre Vor- und Nachteile.

MyISAM eignet sich für einige Anwendungen, die viele Abfragen erfordern, ist jedoch nicht sehr gut für Anwendungen mit vielen Schreibvorgängen. Selbst wenn Sie nur ein Feld aktualisieren müssen, wird die gesamte Tabelle gesperrt und andere Prozesse (auch Leseprozesse) können nicht ausgeführt werden, bis der Lesevorgang abgeschlossen ist. Darüber hinaus ist MyISAM für Berechnungen wie SELECT COUNT(*) extrem schnell.

Der Trend von InnoDB geht dahin, eine sehr komplexe Speicher-Engine zu werden, und für einige kleine Anwendungen wird es langsamer sein als MyISAM. Es unterstützt „Zeilensperren“ und bietet daher bei mehreren Schreibvorgängen eine bessere Leistung. Darüber hinaus unterstützt es auch erweiterte Anwendungen, beispielsweise Transaktionen.

Damit ist dieser Artikel über MySQL-Abfrageoptimierung und eine Tabellenoptimierungslösung für 1 Million Datensätze abgeschlossen. Weitere relevante Inhalte zur MySQL-Abfrageoptimierung finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!