Lösung zur Datenduplizierung bei Verwendung von Limit+Order By in der MySql-Paging

Zusammenfassung

Es ist wichtig, komplexes Wissen einfach erklären zu können

Während des Lernprozesses haben wir viele Materialien, Videos, Dokumente usw. gelesen. Da es mittlerweile so viele Materialien und Videos gibt, gibt es oft verschiedene Videoformen, um einen Wissenspunkt zu erklären. Neben dem Werbemarketing gibt es tatsächlich viele Leute, deren Videoerklärungen hervorragend sind. Beispielsweise können die kurzen Videolektionen von Lehrer Li Yongle solch komplexes Wissen so einfach und gründlich an einer Tafel erklären. Diejenigen unter uns, die Programmieren lernen, müssen nicht nur lernen, die Wissenspunkte klar zu erklären, sondern auch, wie man sie klar schreibt.

Problembeschreibung

In MySQL verwenden wir normalerweise „limit“, um Seitenabfragen durchzuführen. Beispielsweise bedeutet „limit(0,10)“, dass 10 Daten auf der ersten Seite aufgelistet werden, und „limit(10,10)“ bedeutet, dass die zweite Seite aufgelistet wird. Wenn das Limit jedoch die Reihenfolge erreicht, werden die Datensätze der ersten Seite möglicherweise erneut angezeigt, wenn Sie zur zweiten Seite blättern.

Die Einzelheiten lauten wie folgt:

WÄHLEN
  `Posttitel`,
  `Postdatum`
AUS
  Post
WO
  `post_status` = 'veröffentlichen'
BESTELLEN BIS
  Anzahl der Aufrufe absteigend
LIMIT
  5, 5

Bei Verwendung der obigen SQL-Abfrage besteht eine hohe Wahrscheinlichkeit, dass ein mit LIMIT 0,5 identischer Datensatz erscheint. Wenn Sie die folgende Methode verwenden, kommt es zu keiner Duplizierung:

WÄHLEN
  *
AUS
  Post
WO
  post_status = "veröffentlichen"
BESTELLEN BIS
  Anzahl der Aufrufe absteigend
LIMIT
  5, 5

Da die Post-Tabelle jedoch viele Felder hat, möchte ich nur diese beiden Felder verwenden und nicht auch den Post-Inhalt überprüfen. Um dieses Problem zu lösen, werden nach ORDER BY zwei Sortierbedingungen verwendet, wie folgt:

WÄHLEN
  `Posttitel`,
  `Postdatum`
AUS
  Post
WO
  `post_status` = 'veröffentlichen'
BESTELLEN BIS
  Anzahl der Aufrufe absteigend,
  ID aufsteigend
LIMIT
  5, 5

Logischerweise verwendet die MySQL-Sortierung standardmäßig die Primärschlüssel-ID als Sortierbedingung. Das heißt, wenn view_count gleich ist, wird die Primärschlüssel-ID als Standardsortierbedingung verwendet und wir müssen keine ID asc hinzufügen. Tatsache ist jedoch, dass die Sortierung chaotisch wird, wenn MySQL Order By und Limit vermischt.

Analysieren Sie das Problem

In MySQL 5.6 führt der Optimierer eine Optimierung durch, wenn er auf die Anweisung „Order by Limit“ stößt, d. h. unter Verwendung der Prioritätswarteschlange.

Der Zweck der Verwendung der Prioritätswarteschlange besteht darin, dass Sie, wenn die Indexreihenfolge nicht verwendet werden kann, beim Sortieren und Verwenden des Limits n nur n Datensätze während des Sortiervorgangs behalten müssen. Dies kann zwar den Mehraufwand beim Sortieren aller Datensätze nicht lösen, erfordert jedoch nur eine kleine Menge Speicher im Sortierpuffer, um die Sortierung abzuschließen.

Der Grund, warum MySQL 5.6 das Problem doppelter Daten auf der zweiten Seite hat, liegt darin, dass die Prioritätswarteschlange die Heap-Sortiermethode verwendet, eine instabile Sortiermethode. Das heißt, die Sortierergebnisse derselben Werte können mit der Reihenfolge der gelesenen Daten inkonsistent sein.

MySQL 5.5 verfügt nicht über diese Optimierung, daher tritt dieses Problem nicht auf.

Mit anderen Worten, das in diesem Artikel erwähnte Problem besteht in MySQL 5.5 nicht und diese Situation trat erst nach Version 5.6 auf.

Schauen wir uns die Ausführungsreihenfolge an, wenn MySQL die SQL-Sprache interpretiert:

(1) AUSWÄHLEN
(2) DISTINCT <Auswahlliste>
(3) FROM <linke_Tabelle>
(4) <join_type> JOIN <rechte_Tabelle>
(5) ON <Beitrittsbedingung>
(6) WHERE <Wo_Bedingung>
(7) GRUPPE NACH <Gruppenliste>
(8) HAVING <Haben_Bedingung>
(9) ORDER BY <order_by_condition>
(10) LIMIT <Grenzwert>

Die Ausführungsreihenfolge ist Form … wobei … Auswahl … Sortierung nach … Grenze …. Aufgrund der oben erwähnten Prioritätswarteschlange werden nach Abschluss der Auswahl alle Datensätze in Heapsortierung angeordnet. Beim Ausführen von Order by werden nur die Datensätze mit größeren View_Count-Werten nach vorne verschoben.

Aufgrund des Begrenzungsfaktors müssen jedoch während des Sortiervorgangs nur 5 Datensätze beibehalten werden. view_count hat keine Indexreihenfolge. Wenn also die zweite Seite mit Daten angezeigt werden soll, nimmt MySQL den Datensatz, den es sieht. Wenn die Sortierwerte also gleich sind, ist die erste Sortierung zufällig. Wenn das SQL zum zweiten Mal ausgeführt wird, sollte das Ergebnis mit dem ersten Ergebnis identisch sein.

Lösung des Problems

(1) Indexsortierfelder

Wenn Sie dem Feld einen Index hinzufügen, können Sie direkt entsprechend der Reihenfolge des Index lesen und paginieren und so dieses Problem vermeiden.

(2) Paging richtig verstehen

Die Paginierung erfolgt nach Sortierung und ist in Mengenbereiche unterteilt. Beim Sortieren handelt es sich um eine von der Datenbank bereitgestellte Funktion, während die Paginierung eine abgeleitete Anwendungsanforderung ist.

Die offizielle Dokumentation von MySQL und Oracle bietet Methoden für „Limit n“ und „Rownum < n“, definiert das Konzept der Paging jedoch nicht klar.

Ein weiterer wichtiger Punkt ist, dass die obige Lösung dieses Problem zwar für Benutzer lindern kann, nach dem Verständnis der Benutzer jedoch immer noch Probleme bestehen: Beispielsweise wird diese Tabelle häufig eingefügt, und wenn Benutzer eine Abfrage durchführen, überlappen sich die erste und die zweite Seite unter der Isolationsstufe „Read-Commit“ immer noch.

Daher hat dieses Problem beim Paging schon immer bestanden, und in verschiedenen Szenarien werden für das Daten-Paging keine sehr hohen Genauigkeitsanforderungen gestellt.

(3) Einige häufige Probleme beim Sortieren von Datenbanken

Sortierproblem, wenn keine Sortierung hinzugefügt wird

Wenn Benutzer Oracle oder MySQL verwenden, stellen sie fest, dass MySQL immer in Ordnung ist, Oracle jedoch sehr chaotisch ist. Dies liegt hauptsächlich daran, dass Oracle eine Heap-Tabelle und MySQL eine Index-Cluster-Tabelle ist. Wenn keine Sortierreihenfolge angegeben ist, garantiert die Datenbank daher nicht die Reihenfolge, in der die Datensätze zurückgegeben werden, und auch nicht, dass jede Rückgabe konsistent ist.

Seitennummerierungsproblem Seitennummerierungsduplizierungsproblem

Wie oben beschrieben, ist die Paginierung eine Anwendungsanforderung, die sich aus der von der Datenbank bereitgestellten Sortierfunktion ergibt. Die Datenbank garantiert keine Duplizierung der Paginierung.

NULL-Wert und leere Zeichenfolge Problem

Verschiedene Datenbanken verstehen und verarbeiten NULL-Werte und leere Zeichenfolgen unterschiedlich. Beispielsweise können Oracle NULL- und NULL-Werte nicht verglichen werden. Sie sind weder gleich noch ungleich und sind unbekannt. Beim Einfügen eines leeren Strings behandelt MySQL diesen als leeren String mit der Länge 0, während Oracle den NULL-Wert direkt verarbeitet.

Damit ist dieser Artikel zur Lösung des Datenduplizierungsproblems bei Verwendung von Limit+Order By in MySql-Paging abgeschlossen. Weitere Informationen zu MySql Limit+Order By-Paging finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!