Untersuchung der MySQL-Paging-Leistung

Mehrere gängige Paging-Methoden:

1. Rolltreppenmethode

Die Rolltreppenmethode bietet normalerweise nur zwei Navigationsmodi: vorherige Seite/nächste Seite. Einige Produkte bieten nicht einmal die Funktion „vorherige Seite“, sondern nur eine „mehr/mehr“-Methode. Es gibt auch eine Pulldown-Methode zum automatischen Laden weiterer Seiten, die technisch alle als Rolltreppenmethode zusammengefasst werden können.
Die Eskalationsmethode ist in der technischen Umsetzung relativ einfach und effizient. Sie erfordert lediglich, entsprechend dem Offset des letzten Elements auf der aktuellen Seite eine Seite zurückzugehen. In SQL geschrieben könnte ähnlich sein wie

Wählen Sie * aus der Listentabelle, wobei ID > Offset-ID LIMIT n ist.

1. Aufzugsmethode

Eine weitere Möglichkeit, Daten zu erhalten, besteht darin, im Produkt genaue Seitenumbrüche bereitzustellen, z. B. 1, 2, 3 ... n. Benutzer können die Anzahl der Seiten auch direkt in der Navigation eingeben. Aufzüge kommen in China fast überall zum Einsatz, die Kosten für die technische Umsetzung sind allerdings relativ hoch.

In MySQL ist der üblicherweise erwähnte B-Baum in der Implementierung der Speicher-Engine normalerweise B+-Baum.

Wenn der Benutzer bei der Aufzugsmethode angibt, dass er zu Seite n blättern soll, gibt es keine direkte Möglichkeit, den Standort anzusprechen. Stattdessen muss vom ersten Stockwerk aus nacheinander gezählt und bis zur Anzahl*Seite gescannt werden, bevor mit der Datenerfassung begonnen werden kann. Dies führt zu geringer Effizienz.

Traditionelle Paging-Technologie (Aufzugsmethode)

Zuerst muss das Frontend Ihre Paging-Entität und Abfragebedingungen übergeben

//Paging-Entität structFinanceDcPage{
1:i32 pageSize, //Seitenkapazität 2:i32 pageIndex, //aktueller Seitenindex}

Dann müssen Sie die Gesamtzahl der Abfragen an das Front-End zurückgeben.

Wählen Sie COUNT(*) aus meiner_Tabelle aus. WHEREx = y ORDER BY id;

Geben Sie dann die angegebene Anzahl Seiten an das Frontend zurück:

SELECT * FROM my_table WHEREx = y ORDER BY date_colLIMIT (Seitenindex - 1) * Seitengröße, Seitengröße;

Die Ergebnisse der beiden obigen SQL-Anweisungen müssen an die Front-End-Paging-Entität und den Einzelseiten-Ergebnissatz zurückgegeben werden.

//Paging-Entität structFinanceDcPage{
1:i32 pageSize, //Seitenkapazität 2:i32 pageIndex, //aktueller Seitenindex 3:i32 pageTotal, //Gesamtzahl der Seiten 4:i32 totalRecod, //Gesamtzahl der Datensätze}

Bei herkömmlichen Abfragemethoden ändert sich bei jeder Anforderung nur der Seitenindexwert, d. h. der Grenzoffset und der Num-Offset.

Wie z. B. Grenze 0,10; Grenze 10,10; …. Grenze10000,10;

Die oben genannten Änderungen führen dazu, dass die Ausführungszeit jeder Abfrage abweicht. Je größer der Offset-Wert, desto länger ist die erforderliche Zeit. Wenn beispielsweise limit10000,10 verwendet wird, müssen 10010 Datenelemente gelesen werden, um die gewünschten 10 Datenelemente zu erhalten.

Optimierungsmethoden

Wir wissen aus traditionellen Methoden, dass der Schlüssel zur Effizienz darin liegt, dass das Programm viele unnötige Daten durchläuft. Sobald wir den Schlüsselpunkt gefunden haben, beginnen wir von dort aus.

Wenn der Aufzug nicht benutzt werden muss, können wir zur Leistungssteigerung die Rolltreppe nutzen.

Aber in den meisten Fällen kann das Aufzugsformular die Bedürfnisse der Benutzer besser erfüllen, daher müssen wir andere Wege finden, um das Aufzugsformular zu optimieren.

Optimierung auf Basis traditioneller Methoden

Die oben genannten Optimierungsmethoden erfüllen die Benutzeranforderungen entweder nur schwer oder sind zu kompliziert zu implementieren. Wenn die Datenmenge nicht besonders groß ist, z. B. Millionen von Daten, besteht daher eigentlich keine Notwendigkeit, die oben genannten Optimierungsmethoden zu verwenden.

Herkömmliche Methoden sind ausreichend, müssen jedoch unter Umständen optimiert werden. Zum Beispiel:

OrderBy-Optimierung

Wählen Sie * aus pa_dc_flow bestellen nach Betreffcode DESC LIMIT 100000, 5

Diese Anweisung verwendet das Schlüsselwort ORDER BY, daher ist es sehr wichtig, was sortiert wird. Wenn Sie die automatisch inkrementierende ID sortieren, muss diese Anweisung nicht optimiert werden. Wenn es sich um einen Index oder sogar einen Nicht-Index handelt, muss sie optimiert werden.

Zunächst müssen Sie sicherstellen, dass es indiziert ist, sonst wird es sehr langsam. Wenn es sich dann um einen Index handelt, dieser aber nicht wie die Auto-Increment-ID sortiert ist, sollte er wie folgt umgeschrieben werden.

Wählen Sie * aus pa_dc_flow INNER JOIN (Wählen Sie ID aus pa_dc_flow ORDER BY Subject_Code DESC LIMIT 100000, 5) Eine Spa_dc_flow_id USING (ID);

Unten finden Sie die Erklärung zu zwei SQL-Anweisungen

Aus der Abbildung können wir erkennen, dass das zweite SQL weniger Seiten scannen kann.

Tatsächlich handelt es sich hierbei um eine Optimierung der Reihenfolge. Der Subject_Code-Index wird in der ersten SQL-Anweisung nicht verwendet. Wenn Sie stattdessen „Subject_code“ auswählen, wird der Index verwendet. Nachfolgend finden Sie die Optimierung der Reihenfolge nach.

Wenn Sie einen Index für das Feld nach order by verwenden möchten, müssen Sie einen zusammengesetzten Index mit einem Feld in der Where-Bedingung erstellen! ! Mit anderen Worten, wenn das Feld nach orcerby nach Index sortiert werden muss, sollte es entweder einen zusammengesetzten Index mit dem Feld in der Where-Bedingung erstellen [Beim Erstellen eines zusammengesetzten Index muss hier auf die Spaltenreihenfolge des zusammengesetzten Index geachtet werden (Where-Feld, Order-by-Feld), um das Prinzip der am weitesten links stehenden Spalte zu erfüllen. Der Grund kann sein, dass das Order-by-Feld in der Where-Abfragebedingung gezählt werden kann! ], oder es muss selbst in der Where-Bedingung referenziert werden!

Tabelle asubject_code ist ein normales Feld mit einem Index und id ist der automatisch inkrementierte Primärschlüssel

select * from a order by subject_code // Index wird nicht verwendet select id from a order by subject_code // Index kann verwendet werden select subject_code from a order by subject_code // Index kann verwendet werden select * from a where subject_code = XX order by subject_code // Index kann verwendet werden

Das bedeutet, dass Order By die Dateisystemsortierung vermeiden sollte. Platzieren Sie das Order By-Feld entweder nach der Auswahl, verwenden Sie das Order By-Feld in der Where-Bedingung oder erstellen Sie einen zusammengesetzten Index für das Order By-Feld und das Where-Bedingungsfeld!

Die zweite SQL-Anweisung nutzt geschickt die zweite Methode, um den Index zu nutzen. Wählen Sie eine ID aus einer Bestellung nach Betreffcode aus. Diese Methode

Zähloptimierung

Bei sehr großen Datenmengen können Sie sich mithilfe der EXPLAIN-Anweisung die ungefähre Gesamtmenge ausgeben lassen. Dabei wird das SQL nicht wirklich ausgeführt, sondern eine Schätzung vorgenommen.

Zusammenfassen

Oben ist die vom Herausgeber vorgestellte Untersuchung der MySQL-Paging-Leistung. Ich hoffe, sie ist für alle hilfreich. Wenn Sie Fragen haben, hinterlassen Sie mir bitte eine Nachricht und der Herausgeber wird Ihnen rechtzeitig antworten. Ich möchte auch allen für ihre Unterstützung der Website 123WORDPRESS.COM danken!