Ein Artikel zum Erlernen von Fähigkeiten zur Optimierung von MySQL-Indexabfragen

Vorwort

In diesem Artikel sind einige allgemeine Tipps zur Verwendung von MySQL zusammengefasst, die Teams ohne DBA als Referenz dienen können. Sofern nicht anders angegeben, ist die Speicher-Engine InnoDB.

Funktionen von MySQL

Wenn Sie die Eigenschaften von MySQL verstehen, können Sie MySQL besser nutzen. Der größte Unterschied zwischen MySQL und anderen gängigen Datenbanken ist das Konzept der Speicher-Engine, die für das Speichern und Lesen von Daten verantwortlich ist. Verschiedene Speicher-Engines haben unterschiedliche Eigenschaften. Benutzer können basierend auf den Eigenschaften ihres Unternehmens eine geeignete Speicher-Engine auswählen oder sogar eine neue Engine entwickeln. Die logische Architektur von MySQL ist wie folgt:

Die Standard-Speicher-Engine von MySQL ist InnoDB. Die Hauptfunktionen dieser Speicher-Engine sind:

• Unterstützung der Transaktionsverarbeitung
• Unterstützt Sperren auf Zeilenebene
• Daten werden in einem Tabellenbereich gespeichert, der aus einer Reihe von Datendateien besteht.
• Verwenden Sie den MVVC-Mechanismus (Multi-Version Concurrency Control), um eine hohe Parallelität zu erreichen
• Die Tabelle wird basierend auf dem gruppierten Index des Primärschlüssels erstellt.
• Unterstützt Hot-Backup
  

Übersicht über weitere gängige Funktionen von Speicher-Engines:

• MyISAM: Die Standard-Engine für ältere Versionen von MySQL. Sie unterstützt keine Transaktionen und Zeilensperren. Entwickler können Tabellensperren manuell steuern. Sie unterstützt Volltextindizes. Sie kann nach einem Absturz nicht sicher wiederhergestellt werden. Sie unterstützt komprimierte Tabellen. Die Daten in komprimierten Tabellen können nicht geändert werden, aber sie nehmen weniger Speicherplatz ein und können die Abfrageleistung verbessern.
• Archivieren: Unterstützt nur Einfügen und Auswählen. Batch-Einfügen ist sehr schnell. Daten werden durch Scannen der gesamten Tabelle abgefragt.
• SCV: Eine SCV-Datei als Tabelle behandeln
• Speicher: Daten werden im Speicher gespeichert
  

Es gibt noch viele mehr, ich werde sie nicht alle auflisten.

Datentypoptimierung

Grundsätze zur Auswahl von Datentypen:

• Wählen Sie einen Datentyp, der weniger Platz beansprucht
• Wählen Sie einen einfachen Typ
• Vermeiden Sie unnötige Spalten mit Nullwerten.
  

Typen mit geringerem Platzbedarf sparen mehr Hardwareressourcen wie Festplatte, Speicher und CPU. Versuchen Sie, einfache Typen zu verwenden. Verwenden Sie beispielsweise möglichst int statt char, da die Sortierung bei letzterem die Auswahl von Zeichensätzen erfordert, was komplizierter ist als die Verwendung von int. Nullable-Spalten verwenden mehr Speicherplatz und wenn Sie einen Index für eine Nullable-Spalte erstellen, benötigt MySQL zusätzliche Bytes für die Datensatzführung. Beim Erstellen einer Tabelle ist der Standardwert nullfähig, was von Entwicklern leicht übersehen wird. Am besten ändern Sie ihn manuell in nicht nullfähig, wenn die zu speichernden Daten definitiv keine Nullwerte enthalten.

Ganzzahltypen

Zu den Integer-Typen zählen:

• winzige
• kleinint
• Mittelwert
• int
• groß
  

Sie verwenden 8, 16, 24, 32 und 64 Bits, um Zahlen zu speichern, und sie können darstellen

Den Zahlen im Bereich kann der Modifikator „unsigned“ vorangestellt werden, wodurch sich der darstellbare Bereich positiver Zahlen verdoppeln kann, negative Zahlen jedoch nicht dargestellt werden können. Darüber hinaus ist es sinnlos, für eine Ganzzahl eine Länge anzugeben. Sobald der Datentyp bestimmt ist, wird auch die Länge entsprechend bestimmt.

Dezimaltyp

• schweben
• doppelt
• dezimal
  

Float und Double sind einfach die üblichen Float- und Double-Werte. Ersteres verwendet 32 ​​Bits zum Speichern von Daten, während Letzteres 64 Bits zum Speichern von Daten verwendet. Wie bei Ganzzahlen ist es sinnlos, für sie eine Länge anzugeben.

Der Dezimaltyp ist komplexer, unterstützt präzise Berechnungen und nimmt viel Platz ein. Dezimal verwendet 4 Bytes, um 9 Ziffern darzustellen. Beispielsweise bedeutet decimal(18,9), dass die Länge der Zahl 18 beträgt, einschließlich 9 Dezimalstellen, 9 Ganzzahlen und dem Dezimalpunkt selbst, was insgesamt 9 Bytes einnimmt. Da Dezimalzahlen mehr Platz beanspruchen und die Genauigkeitsberechnung sehr kompliziert ist, können Sie bei großen Datenmengen stattdessen Bigint verwenden. Sie können vor dem Speichern und Lesen einige Skalierungsvorgänge an den realen Daten durchführen.

Zeichenfolgentyp

• varchar
• verkohlen
• varbinary
• binär
• Klecks
• Text
• aufzählen

Der tatsächlich von Daten des Typs varchar belegte Speicherplatz entspricht der Länge der Zeichenfolge plus 1 oder 2 Bytes, die zum Aufzeichnen der Länge der Zeichenfolge verwendet werden (wenn das Zeilenformat nicht auf fest eingestellt ist). Varchar spart viel Speicherplatz. Wenn die Länge der Zeichenfolgendaten in einer Spalte einer Tabelle stark variiert, ist die Verwendung von varchar sinnvoll.

Der tatsächlich von char belegte Speicherplatz ist festgelegt. Wenn die Längen der Zeichenfolgendaten in der Tabelle nahezu gleich oder sehr kurz sind, ist die Verwendung des Diagrammtyps angemessen.

Varchar und char entsprechen varbinary und binary. Letzteres speichert binäre Zeichenfolgen. Im Vergleich zu ersterem ist letzteres case-sensitiv, muss die Codierungsmethode nicht berücksichtigen und ist bei der Durchführung von Vergleichsoperationen schneller.

Es ist zu beachten, dass varchar(5) und varchar(200) zwar beim Speichern der Zeichenfolge „Hallo“ denselben Speicherplatz verwenden, dies jedoch nicht bedeutet, dass die Leistung nicht beeinträchtigt wird, wenn die Länge von varchar zu groß eingestellt wird. Tatsächlich weisen einige interne Berechnungen von MySQL, z. B. das Erstellen temporärer Tabellen im Speicher (einige Abfragen führen dazu, dass MySQL automatisch temporäre Tabellen erstellt), eine feste Größe an Speicherplatz zum Speichern von Daten zu.

Blob verwendet binäre Zeichenfolgen zum Speichern großer Texte, und Text verwendet Zeichen zum Speichern großer Texte. InnoDB verwendet einen dedizierten externen Speicherbereich zum Speichern solcher Daten, und nur Zeiger darauf werden in der Datenzeile gespeichert. Es ist nicht geeignet, Indizes für solche Daten zu erstellen (wenn Sie einen erstellen müssen, können Sie ihn nur für das Zeichenfolgenpräfix erstellen), aber das wird niemand tun.

Wenn eine Zeichenfolgenspalte in großen Mengen wiederholt wird und nur begrenzten Inhalt hat, können Sie stattdessen Aufzählungen verwenden. MySQL verwaltet bei der Verarbeitung von Aufzählungen eine „Zahl-Zeichenfolge“-Tabelle. Durch die Verwendung von Aufzählungen kann viel Speicherplatz gespart werden.

Zeittyp

• Jahr
• Datum
• Zeit
• Datum/Uhrzeit
• Zeitstempel
  

Der Datums-/Uhrzeitspeicherbereich reicht von 1001 bis 9999 und ist auf die Sekunde genau. Der Zeitstempel speichert die Anzahl der Sekunden seit Mitternacht, 1. Januar 1970 und kann bis 2038 dargestellt werden. Es belegt 4 Bytes, also die Hälfte des von datetime belegten Speicherplatzes. Die durch den Zeitstempel dargestellte Zeit bezieht sich auf die Zeitzone. Darüber hinaus verfügt die Zeitstempelspalte über eine weitere Funktion. Beim Ausführen einer Einfüge- oder Aktualisierungsanweisung aktualisiert MySQL die Daten der ersten Spalte vom Typ Zeitstempel automatisch auf die aktuelle Zeit. Viele Tabellen verfügen über eine Spalte mit dem Namen UpdateTime. Es ist durchaus sinnvoll, für diese Spalte einen Zeitstempel zu verwenden, der automatisch aktualisiert wird, vorausgesetzt, das System wird erst im Jahr 2038 verwendet.

Auswahl des Primärschlüsseltyps

Verwenden Sie nach Möglichkeit ganze Zahlen. Ganze Zahlen benötigen weniger Platz und können so eingestellt werden, dass sie automatisch wachsen. Verwenden Sie insbesondere keine Hashwertzeichenfolgen wie GUID, MD5 usw. als Primärschlüssel. Diese Zeichenfolgen sind sehr zufällig. Da der InnoDB-Primärschlüssel standardmäßig eine Clustered-Index-Spalte ist, ist die Datenspeicherung zu verstreut. Darüber hinaus enthält die Sekundärindexspalte von InnoDB standardmäßig die Primärschlüsselspalte. Wenn der Primärschlüssel zu lang ist, nimmt auch der Sekundärindex viel Platz ein.

Besondere Arten von Daten

Zum Speichern von IP-Adressen empfiehlt sich die Verwendung einer vorzeichenlosen 32-Bit-Ganzzahl. MySQL bietet die Funktionen inet_aton() und inet_ntoa() zum Konvertieren zwischen der digitalen Darstellung und der Zeichenfolgendarstellung von IP-Adressen.

Indexoptimierung

InnoDB verwendet B+-Baum, um den Index zu implementieren. Angenommen, es gibt eine People-Tabelle, dann lautet die Anweisung zur Tabellenerstellung wie folgt

CREATE TABLE `Personen` (
 `Id` int(11) NICHT NULL AUTO_INCREMENT,
 `Name` varchar(5) NICHT NULL,
 `Alter` tinyint(4) NICHT NULL,
 `Zahl` char(5) NICHT NULL KOMMENTAR 'Zahl',
 Primärschlüssel (`Id`),
 SCHLÜSSEL `i_name_age_number` (`Name`,`Alter`,`Nummer`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8;

Daten einfügen:

Die Indexstruktur ist ungefähr wie folgt:

Mit anderen Worten, die Reihenfolge der Indexspalten ist sehr wichtig. Wenn die Spalten „Name“ zweier Datenzeilen gleich sind, wird die Spalte „Alter“ zum Vergleichen der Größen verwendet. Wenn die Spalten „Alter“ gleich sind, wird die Spalte „Zahl“ zum Vergleichen der Größen verwendet. Sortieren Sie zuerst nach der ersten Spalte, dann nach der zweiten Spalte und schließlich nach der dritten Spalte.

Bei der Verwendung von Abfragen sollten Sie versuchen, von links nach rechts abzugleichen. Wenn Sie außerdem den linken Spaltenbereich durchsuchen, kann die rechte Spalte den Index nicht verwenden. Sie können auch nicht nach alternativen Spalten suchen, da sonst die nachfolgenden Indizes nicht verwendet werden können. Die folgenden SQL-Anweisungen sind positive Beispiele:

• SELECT * from people where Name = 'Abel' und Alter = 2 AND Nummer = 12312
• SELECT * von Personen, bei denen Name = "Abel"
• SELECT * von Personen mit Namen wie „Abel%“
• SELECT * from people where Name = 'Andy' und Alter ZWISCHEN 11 und 20
• SELECT * von Personen ORDER BY NAME
• SELECT * von Personen ORDER BY NAME, Alter
• SELECT * von Personen GROUP BY Name
  

Die folgenden SQL-Anweisungen sind Negativbeispiele:

• SELECT * von Personen, bei denen Alter = 2
• SELECT * von Personen, deren NAME wie '%B' ist
• SELECT * von Personen mit Alter = 2
• SELECT * von Personen, bei denen NAME = 'ABC' UND Nummer = 3
• SELECT * von Personen, bei denen NAME wie 'B%' und Alter = 22 ist
  

Eine Technik zum Erstellen von Indizes mithilfe von Hash-Werten

Wenn die Tabelle eine Spalte enthält, die lange Zeichenfolgen speichert (sagen wir, der Name ist eine URL), ist der für diese Spalte erstellte Index groß. Es gibt eine Möglichkeit, dies zu verringern: Erstellen Sie einen Index für den numerischen Hashwert der URL-Zeichenfolge. Erstellen Sie ein neues Feld, beispielsweise URL_CRC, um den Hashwert der URL zu speichern, erstellen Sie dann einen Index für dieses Feld und schreiben Sie die folgende Abfrage:

Wählen Sie * aus t, wobei URL_CRC = 387695885 und URL = „www.baidu.com“

Um Hash-Konflikte bei großen Datenmengen zu vermeiden, können Sie die Hash-Funktion anpassen oder einen Teil des Rückgabewerts der MD5-Funktion als Hash-Wert verwenden:

Wählen Sie CONV (RECHTS (MD5 ('www.baidu.com'), 16), 16, 10)

Präfixindex

Wenn die in der Zeichenfolgenspalte gespeicherten Daten lang sind und der erstellte Index ebenfalls groß ist, können Sie einen Präfixindex verwenden, d. h. nur die ersten paar Zeichen der Zeichenfolge indizieren. Dadurch kann die Indexgröße verkürzt werden. Allerdings funktioniert dieser Indextyp offensichtlich nicht bei der Ausführung von „order by“ und „group by“.

Beim Erstellen eines Präfixindex ist es wichtig, die Präfixlänge auszuwählen. Versuchen Sie, ein kürzeres Präfix zu wählen, ohne die ursprüngliche Datenverteilung zu zerstören. Wenn beispielsweise die meisten Zeichenfolgen mit „abc“ beginnen und die Präfixindexlänge auf 4 begrenzt ist, enthält der Indexwert zu viele wiederholte „abcX“.

Mehrspaltige Indizes

Der oben erwähnte für „Personen“ erstellte Index ist ein mehrspaltiger Index, der oft besser ist als mehrere einspaltige Indizes.

• Wenn Sie UND-Abfragen auf mehreren Indizes durchführen, sollten Sie mehrspaltige Indizes anstelle mehrerer einspaltiger Indizes erstellen.
• Sie können versuchen, Folgendes zu schreiben:
  

wähle * aus t, wobei f1 = 'v1' und f2 <> 'v2' alles vereinigen wähle * aus t, wobei f2 = 'v2' und f1 <> 'v1'

Die Reihenfolge mehrspaltiger Indizes ist sehr wichtig. Wenn Sortier- und Gruppierungsabfragen nicht berücksichtigt werden, sollten Spalten mit hoher Selektivität (Selektivität bezieht sich auf die Anzahl unterschiedlicher Daten in einer Tabellenindexspalte/Gesamtzahl der Zeilen. Hohe Selektivität bedeutet weniger doppelte Daten) normalerweise an den Anfang gestellt werden. Es gibt jedoch Ausnahmen. Wenn Sie feststellen können, dass einige Abfragen häufig ausgeführt werden, sollten Sie der Selektivität dieser Abfragen Priorität einräumen. Wenn beispielsweise die Selektivität von Name in der obigen Tabelle „Personen“ größer ist als Age, sollte die Abfrageanweisung folgendermaßen geschrieben werden:

Wählen Sie * aus Personen aus, bei denen Name = 'xxx' und Alter = xx

Es ist sinnvoller, die Spalte Name auf der linken Seite des Index zu platzieren. Wenn jedoch eine bestimmte SQL-Ausführungsrate am höchsten ist, wie z. B.

Wählen Sie * aus Personen aus, bei denen Name = 'xxx' und Alter = 20

Wenn in der Datenbank nur sehr wenige Datensätze mit Alter=20 vorhanden sind, ist es effizienter, das Alter am linken Ende der Indexspalte einzutragen. Das Eintragen des Alters auf der linken Seite des Index kann gegenüber anderen Abfragen unfair sein, bei denen das Alter ungleich 20 ist. Wenn Sie nicht sicher sind, ob Alter=20 die häufigste Abfragebedingung ist, müssen Sie dennoch alle Faktoren berücksichtigen und es ist angemessener, den Namen auf die linke Seite zu setzen.

Gruppierter Index

Ein Clustered-Index ist eine Datenspeicherstruktur. InnoDB speichert Datenzeilen direkt in den Blattknoten des Primärschlüsselindex, anstatt wie bei einem Sekundärindex nur die Werte der Indexspalten und die Primärschlüsselwerte der Zeilen zu speichern, auf die verwiesen wird. Aufgrund dieser Funktion kann eine Tabelle nur einen gruppierten Index haben. Wenn eine Tabelle keinen Primärschlüssel oder eine Spalte mit einem eindeutigen Index definiert, generiert InnoDB eine versteckte Spalte und legt sie als gruppierte Indexspalte fest.

Abdeckungsindex

Einfach ausgedrückt müssen einige Abfragen nur die Indexspalte abfragen, sodass keine sekundäre Abfrage basierend auf der im Index-B-Baumknoten aufgezeichneten Primärschlüssel-ID durchgeführt werden muss.

Doppelte und redundante Indizes

Wenn Sie wiederholt einen Index für eine Spalte erstellen, bringt dies keine Vorteile, sondern nur Nachteile. Versuchen Sie daher, dies zu vermeiden. Beispielsweise ist es redundant, einen eindeutigen Index und einen normalen Index für den Primärschlüssel zu erstellen, da der Primärschlüssel von InnoDB standardmäßig ein gruppierter Index ist.

Redundante Indizes unterscheiden sich von doppelten Indizes. Wenn beispielsweise ein Index (A,B) und ein anderer Index (A) ist, wird dies als redundanter Index bezeichnet. Ersterer kann letzteren ersetzen, letzterer kann ersteren jedoch nicht ersetzen. Allerdings sind (A,B) und (B) sowie (A,B) und (B,A) keine redundanten Indizes und keiner kann den anderen ersetzen.

Wenn in einer Tabelle bereits ein Index (A) vorhanden ist und Sie einen Index (A, B) erstellen möchten, müssen Sie lediglich den vorhandenen Index erweitern. Es ist nicht erforderlich, einen neuen Index zu erstellen. Es ist zu beachten, dass, wenn bereits ein Index (A) vorhanden ist, kein weiterer Index (A, ID) erstellt werden muss, wobei sich ID auf den Primärschlüssel bezieht, da Index A standardmäßig bereits den Primärschlüssel enthält und als redundanter Primärschlüssel gilt.

Manchmal sind redundante Indizes jedoch wünschenswert. Wenn beispielsweise ein vorhandener Index (A) vorhanden ist und dieser auf (A, B) erweitert wird, ist die Abfrage von A allein nicht mehr so ​​schnell wie zuvor, weil Spalte B ein sehr langer Typ ist. In diesem Fall können Sie die Erstellung eines neuen Index (A, B) in Betracht ziehen.

Unbenutzte Indizes

Unbenutzte Indizes erhöhen lediglich die Effizienz von Einfüge-, Aktualisierungs- und Löschvorgängen und sollten zeitnah gelöscht werden.

Zusammenfassung der Indexverwendung

Drei-Sterne-Prinzip der Indizierung:

• Ein Index, der abfragebezogene Datensätze in einer bestimmten Reihenfolge zusammenstellt, erhält einen Stern.
• Ein Stern, wenn die Reihenfolge der Daten im Index mit der Reihenfolge der Abfrageergebnisse übereinstimmt
• Ein Stern, wenn der Index alle von der Abfrage benötigten Spalten enthält
  

Das erste Prinzip bedeutet, dass die Reihenfolge der Abfragen in der Where-Bedingung mit dem Index übereinstimmt, d. h., wie oben erwähnt, der Index von links nach rechts verwendet wird.

Indizes sind kein Allheilmittel. Bei großen Datenmengen ist die Verwaltung des Indexes selbst sehr leistungsintensiv und Sie sollten über Partitionierung und Tabellenspeicherung nachdenken.

Abfrageoptimierung

Gründe für langsame Abfragen

Ob zusätzliche Zeilen von der Datenbank angefordert wurden

Beispielsweise benötigt die Anwendung nur 10 Daten, fordert jedoch alle Daten aus der Datenbank an und verwirft die meisten Daten, bevor sie auf der Benutzeroberfläche angezeigt werden.

Ob zusätzliche Spalten von der Datenbank angefordert werden

Beispielsweise muss die Anwendung nur 5 Spalten anzeigen, aber alle Spalten werden durch select * from überprüft.

Ob die gleiche Abfrage mehrmals ausgeführt wird

Kann die Anwendung eine einmalige Abfrage und Zwischenspeicherung in Betracht ziehen und dann bei späterem Bedarf die Datensätze aus der ersten Abfrage verwenden?

Scannt MySQL zusätzliche Datensätze?

Durch Anzeigen des Ausführungsplans können Sie sich einen ungefähren Überblick über die Anzahl der zu scannenden Datensätze verschaffen. Wenn diese Zahl die Erwartungen übersteigt, versuchen Sie, das Problem durch Hinzufügen von Indizes, Optimieren von SQL (das im Mittelpunkt dieses Abschnitts steht) oder Ändern der Tabellenstruktur (z. B. Hinzufügen einer separaten Übersichtstabelle speziell für eine bestimmte Anweisungsabfrage) zu lösen.

Möglichkeiten zur Neustrukturierung Ihrer Abfrage

• Aufteilen einer komplexen Abfrage in mehrere einfache Abfragen
• Teilen Sie große Abfragen in kleinere mit jeweils gleicher Abfragefunktionalität auf und führen Sie nur einen kleinen Teil aus.
• Zerlegen Sie die zugehörige Abfrage. Sie können eine große verknüpfte Abfrage so ändern, dass mehrere Tabellen separat abgefragt werden, und diese dann im Anwendungscode verarbeiten.
  

Verschiedenes

Optimierung von count()

Count hat zwei Funktionen: Eine besteht darin, die angegebenen Spalten oder Ausdrücke zu zählen, und die andere darin, die Anzahl der Zeilen zu zählen. Wenn der Parameter einen Spaltennamen oder einen Ausdruck übergibt, zählt count alle Zeilen, deren Ergebnisse nicht NULL sind. Wenn der Parameter * ist, zählt count alle Zeilen. Hier ist ein Beispiel für die Übergabe eines Ausdrucks:

SELECT count(Name wie „B%“) aus Personen

• Sie können anstelle von count() ungefähre Optimierungen verwenden, beispielsweise die Anzahl der Zeilen im Ausführungsplan.
• Index-Abdeckungs-Scan
• Zusammenfassungstabelle hinzufügen
• Erhöhen Sie die Anzahl der Datensätze im Speicher-Cache-System
  

Optimieren zugehöriger Abfragen

• Der MySQL-Optimierer führt verwandte Tabellenabfragen wie diese aus. Wenn beispielsweise zwei Tabellen A und B über die Spalte c miteinander verbunden sind, durchsucht MySQL die Tabelle A und sucht dann basierend auf dem Wert der Spalte c nach Daten in Tabelle B. Zusammenfassend lässt sich sagen, dass Sie, wenn kein Index vorhanden ist, normalerweise nur einen Index zur Spalte c der Tabelle B hinzufügen müssen.
• Stellen Sie sicher, dass die an „order by“ und „group by“ beteiligten Spalten nur zu einer Tabelle gehören, damit der Index eine Rolle spielen kann.
  

Unterabfragen optimieren

Versuchen Sie für MySQL 5.5 und darunter, Joins anstelle von Unterabfragen zu verwenden.

Optimieren Sie „Gruppieren nach“ und „Unterscheiden“

Versuchen Sie wenn möglich, beide Operationen auf den Primärschlüssel anzuwenden.

Optimieren Sie das Limit, beispielsweise SQL

Wählen Sie * aus sa_stockinfo ORDER BY StockAcc LIMIT 400, 5

Der MySQL-Optimierer findet alle Spaltendaten für 405 Zeilen und verwirft dann 400. Wenn Sie die Indexabfrage abdecken können, müssen Sie nicht so viele Spalten abfragen. Ändern Sie sie zunächst wie folgt:

SELECT * FROM sa_stockinfo i JOIN (SELECT StockInfoID FROM sa_stockinfo ORDER BY StockAcc LIMIT 400,5)t ON i.StockInfoID = t.StockInfoID

Indizes basieren auf StockAcc. Diese Abfrage verwendet die Indexabdeckung, um schnell die Primärschlüssel zu finden, die die Bedingungen erfüllen, und führt dann eine gemeinsame Abfrage aus. Der Effekt ist offensichtlich, wenn die Datenmenge groß ist.

Optimierung der Vereinigung

Wenn dies nicht erforderlich ist, stellen Sie sicher, dass Sie das Schlüsselwort „union all“ verwenden, sodass MySQL beim Einfügen der Daten in die temporäre Tabelle keine Eindeutigkeitsprüfung durchführt.

Um festzustellen, ob ein Datensatz vorhanden ist, ist der übliche Ansatz

wähle count(*) aus t, wobei Bedingung

Besser ist es zu schreiben:

SELECT IFNULL((SELECT 1 aus Tabellenname, wobei Bedingung LIMIT 1 ist),0)

Zusammenfassen

Dies ist das Ende dieses Artikels über MySQL-Indexabfrageoptimierungstechniken. Weitere relevante MySQL-Indexabfrageoptimierungstechniken 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!