Optimierte Implementierung von count() für große MySQL-Tabellen

Das Folgende ist mein Urteil basierend auf der Datenstruktur des B+-Baums und meiner Spekulation über die experimentellen Ergebnisse. Wenn es Fehler gibt, korrigieren Sie mich bitte!

Heute habe ich mit der Optimierung der MySQL count()-Operation experimentiert. Die folgende Diskussion basiert auf der MySQL 5.7 InnoDB-Speicher-Engine und dem x86-Windows-Betriebssystem.

Die Struktur der erstellten Tabelle ist wie folgt (die Datenmenge beträgt 1 Million):

Zunächst stellt sich die Frage, welches der MySQL-Verfahren count(*), count(PK) und count(1) schneller ist.
Die Ergebnisse sind wie folgt:

Es gibt keinen Unterschied! Nach dem Hinzufügen der WHERE-Klausel ist auch die Zeit für die drei Abfragen gleich, daher werde ich die Bilder nicht veröffentlichen.

Als ich vorher in der Firma gearbeitet habe, habe ich eine SQL-Anweisung „ select count(*) from table geschrieben, die bei vielen Daten sehr langsam war. Wie kann es also optimiert werden?

Dies beginnt mit dem InnoDB-Index. Der InnoDB-Index ist B+Tree.

Für den Primärschlüsselindex gilt: Er speichert nur Daten auf Blattknoten, sein Schlüssel ist der Primärschlüssel und sein Wert sind die gesamten Daten .
Bei Hilfsindizes gilt: „Schlüssel“ ist die Spalte zum Erstellen des Index und „Wert“ ist der Primärschlüssel.

Dadurch erhalten wir zwei Informationen:
1. Die gesamten Daten werden nach dem Primärschlüssel gefunden
2. Nur der Primärschlüssel kann basierend auf dem Sekundärindex gefunden werden, und dann müssen die restlichen Informationen über den Primärschlüssel gefunden werden.

Wenn wir also die count(*)-Operation optimieren möchten, müssen wir eine kurze Spalte finden und einen sekundären Index dafür erstellen.
In meinem Fall ist es status , obwohl sein „Schweregrad“ fast 0 ist.

Erstellen Sie zuerst einen Index: ALTER TABLE test1 ADD INDEX ( status );
Führen Sie dann die Abfrage wie unten gezeigt durch:

Es ist ersichtlich, dass die Abfragezeit von 3,35 s auf 0,26 s gesunken ist und die Abfragegeschwindigkeit um fast das 13-fache zugenommen hat.

Wenn der Index die str Spalte ist, was ist das Ergebnis?
Erstellen Sie zuerst einen Index: alter table test1 add index (str)
Die Ergebnisse sind wie folgt:

Wie Sie sehen, beträgt die Zeit 0,422 s, was ebenfalls sehr schnell ist, aber immer noch etwa 1,5-mal langsamer als status .

Um etwas mutiger zu sein, werde ich ein Experiment durchführen. Ich werde den Index der status löschen, einen gemeinsamen Index von status und left(omdb,200) erstellen (diese Spalte hat durchschnittlich 1000 Zeichen) und dann die Abfragezeit überprüfen.
Erstellen Sie einen Index: alter table test1 add index ( status ,omdb(200))
Die Ergebnisse sind wie folgt:

Die Zeit beträgt 1,172 s

Tabelle ändern test1, Index hinzufügen (Status, Imdbid);

Nachfüllen! !
Seien Sie vorsichtig bei Indexfehlern!
Nachdem der Index erstellt wurde, sieht er folgendermaßen aus:

Sie können sehen, dass key_len 6 ist und die Beschreibung von Extra einen Index verwendet.

Wenn der Index fehlschlägt:

Es gibt viele Situationen, in denen Indizes ungültig werden, z. B. bei der Verwendung von Funktionen, !=-Operationen usw. Einzelheiten finden Sie in der offiziellen Dokumentation.

Ich habe MySQL nicht eingehend untersucht und das Obige basiert auf meiner Beurteilung auf der Grundlage der B+-Baumdatenstruktur und Spekulationen über experimentelle Ergebnisse. Wenn es Fehler gibt, korrigieren Sie mich bitte!

Dies ist das Ende dieses Artikels über die optimierte Implementierung von count() für große MySQL-Tabellen. Weitere relevante Inhalte zur count()-Optimierung für große MySQL-Tabellen 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!