Ich habe eine Web-App, in der ich eine Reihe von Posts basierend auf diesem Tabellenschema zeige (es gibt Tausende von Zeilen wie dieser und andere Spalten) (entfernt, da für diese Frage nicht erforderlich)): -
%Vor%Und ich benutze diese Abfrage: -
%Vor%Und die resultierende Ergebnismenge ist wie folgt: -
%Vor%Beachten Sie, dass die Spalte IDs durch die Klausel order by durcheinander ist.
Ich habe richtige Indizes, um diese Abfragen zu optimieren.
Lassen Sie mich das wahre Problem erklären. Ich habe eine Lazy-Load-Funktion in meiner Web-App. Also zeige ich ungefähr 10 Beiträge pro Seite an, indem ich nach der Abfrage für die erste Seite LIMIT 10 verwende.
Wir sind gut bis hier. Aber das eigentliche Problem kommt, wenn ich die zweite Seite laden muss. Was frage ich jetzt? Ich möchte nicht, dass die Beiträge wiederholt werden. Und es gibt fast alle 15 Sekunden neue Posts, die sie an die Spitze der Ergebnismenge bringen (ich meine die erste Zeile). Ich möchte diese letzten Posts nicht auf der zweiten oder dritten Seite anzeigen, aber sie verändern die Ergebnismenge, so dass ich LIMIT 10,10 nicht für die 2. Seite usw. verwenden kann, da die Beiträge wiederholt werden.).
Nun, alles, was ich weiß, ist die letzte ID des Posts, den ich angezeigt habe. Sage 21 hier. Also, ich möchte die Posts der IDs 23,4,32,58,61,43 anzeigen (siehe Tabelle resultset). Jetzt lade ich alle Zeilen, ohne die LIMIT -Klausel zu verwenden, und zeige 10 IDs nach der ID 21 an. Aber dafür muss ich über tausende von nutzlosen Zeilen intervenieren. Aber ich kann eine LIMIT -Klausel für die 2., 3. ... Seiten nicht verwenden. Auch die IDs sind durcheinander, so dass ich definitiv WHERE ID>... nicht verwenden kann. Also, wo gehen wir jetzt hin?
Hmm ..
Ich habe eine Weile nachgedacht und mir 2 Lösungen ausgedacht. : -
Um die IDs des bereits angezeigten Posts zu speichern und WHERE ID NOT IN(id1,id2,...) abzufragen. Aber das würde dir zusätzlichen Speicher kosten. Und wenn der Benutzer 100 Seiten lädt und die IDs in 100000 sind, dann könnte eine einzelne GET-Anfrage nicht damit umgehen. Zumindest nicht in allen Browsern. Eine POST-Anfrage kann verwendet werden.
Ändern Sie die Anzeige von Posts von COL1 . Ich weiß nicht, ob das ein guter Weg für dich wäre. Aber es kann Ihnen Bandbreite sparen und Ihren Code sauberer machen. Es könnte auch ein besserer Weg sein. Ich würde dies vorschlagen: - SELECT * from TABLE where COL1 IS NOT NULL AND COL2 IS NULL AND Id>.. ORDER BY ID DESC LIMIT 10,10 . Dies kann sich auf die Art und Weise auswirken, wie Sie Ihre Posts nach Sprüngen anzeigen. Aber, wie Sie in Ihren Kommentaren sagten, dass Sie überprüfen, ob ein Beitrag ein Kriterium erfüllt und den COL1 von NULL zum aktuellen Zeitstempel ändert, denke ich, dass je neuer die Beiträge sind, desto mehr wollen Sie sie anzeigen. Es ist nur eine Idee.
Ich bin mir nicht sicher, ob ich deine Frage richtig verstanden habe, aber hier ist, wie ich denke, ich würde es tun:
date_added
LIMIT 10 ) und hängen Sie an den Zeitstempel des letzten Datensatzes; nennen wir es last_date_added . date_added > last_date_added auszufiltern, und verwenden Sie LIMIT 10, 10 , LIMIT 20, 10 , LIMIT 30, 10 usw. Dies hat den Effekt, dass Sie Ihre Ergebnismenge rechtzeitig einfrieren und bei jedem Zugriff auf die erste Seite zurücksetzen.
Hinweise:
last_date_added zu erhalten. Alternativ könnten Sie einfach zum aktuellen Zeitpunkt abbrechen, d. H. Zu der Zeit, zu der auf die erste Seite zugegriffen wurde. Ich nehme an, dass neue Beiträge mit einer höheren ID als die aktuelle max ID rechts hinzugefügt werden? Könnten Sie nicht einfach Ihre Abfrage ausführen und die aktuelle maximale ID abrufen? Wenn Sie dann nach Seite 2 suchen, führen Sie die gleiche Abfrage aus, aber mit "ID & lt; max_id". Dies sollte Ihnen das gleiche Ergebnis geben wie Ihre Abfrage auf Seite 1, da alle neuen Zeilen die ID & gt; max_id Hoffe das hilft?