Ich habe also eine interessante Frage, von der ich nicht sicher bin, ob sie als "Hack" betrachtet wird oder nicht. Ich habe einige Fragen durchgesehen, aber kein Duplikat gefunden, also ist es hier. Grundsätzlich muss ich wissen, ob dies unzuverlässig ist oder als schlechte Praxis angesehen wird.
Ich habe eine sehr einfache Tabelle mit einer eindeutigen automatisch inkrementierenden ID und einem created_at Zeitstempel. (vereinfachte Version meines Problems, um das fragliche Konzept zu klären)
%Vor%Diese beiden Spalten werden dynamisch hinzugefügt, so dass gesagt werden kann, dass ein neues 'Einfügen' IMMER eine größere ID und IMMER ein größeres Datum haben wird.
ZIEL - nehmen Sie einfach die Ergebnisse von created_at in absteigender Reihenfolge
SOLUTION ONE - Eine Abfrage, die nach dem Datum in absteigender Reihenfolge sortiert
%Vor%SOLUTION ZWEI - Eine Abfrage, die nach ID in absteigender Reihenfolge sortiert
%Vor%Wird Lösung zwei als schlechte Praxis angesehen? Oder ist Lösung zwei der richtige Weg, Dinge zu tun. Jede Erklärung Ihrer Überlegungen wäre sehr hilfreich, da ich versuche, das Konzept zu verstehen und nicht einfach eine Antwort zu bekommen. Vielen Dank im Voraus.
In der typischen Praxis können Sie fast immer davon ausgehen, dass eine Autoinkrement-ID so sortiert werden kann, dass Sie die Datensätze in der Erstellungsreihenfolge (in beide Richtungen) erhalten. Sie sollten jedoch beachten, dass dies in Bezug auf Ihre Daten nicht als tragbar gilt. Sie können Ihre Daten auf ein anderes System verschieben, auf dem die Schlüssel neu erstellt werden, aber die Daten created_at sind identisch.
Es gibt tatsächlich eine ziemlich gute StackOverflow Diskussion dieser Ausgabe.
Die grundlegende Zusammenfassung ist die erste Lösung, Bestellung von created_at, gilt als Best Practice. Achten Sie jedoch darauf, das Feld created_at richtig zu indizieren, um die beste Leistung zu erzielen.
Sie sollten sich nicht auf eine ID verlassen, um eine Zeile eindeutig zu identifizieren. Es ist eine willkürliche Zahl, die nur zufällig der Reihenfolge entspricht, in der die Datensätze erstellt wurden.
Sagen Sie, Sie haben diese Tabelle
%Vor%In diesem Fall funktioniert das Sortieren nach ID anstelle von creation_date.
Jetzt in der Zukunft werden Sie feststellen, oh, hoppla, Sie müssen das Erstellungsdatum der Datensatz-ID # 2 bis 2010-09-17 ändern. Ihre Sortierungen, die ID verwenden, melden jetzt die Datensätze in derselben Reihenfolge:
%Vor%obwohl sie mit dem neuen Datum sein sollten:
%Vor%Kurzversion: Verwenden Sie Datenspalten für den Zweck, zu dem sie erstellt wurden. Verlassen Sie sich nicht auf Nebenwirkungen der Daten.
Es gibt ein paar Unterschiede zwischen den beiden Optionen.
Erstens können sie unterschiedliche Ergebnisse liefern.
Der Wert von created_at wird möglicherweise von der Zeit beeinflusst, die auf dem Server eingestellt wird, aber die Spalte id bleibt davon unberührt. Wenn die Zeit rückwärts eingestellt wird (entweder manuell oder automatisch durch die Zeitsynchronisierungssoftware), könnten Sie Datensätze erhalten, die später eingefügt wurden, aber mit Zeitstempeln, die vor Datensätzen liegen, die früher eingefügt wurden. In diesem Fall erhalten Sie eine andere Reihenfolge, abhängig davon, welche Spalte Sie bestellen. Welche Reihenfolge Sie für richtig halten, liegt an Ihnen.
Die zweite ist Leistung. Es ist wahrscheinlich schneller zu ORDER BY Ihres Clustered-Index .
Wie der gruppierte Index Anfragen beschleunigt
Der Zugriff auf eine Zeile durch den gruppierten Index erfolgt schnell, da sich die Zeilendaten auf derselben Seite befinden, auf der die Indexsuche führt.
Standardmäßig ist der gruppierte Schlüssel der Primärschlüssel, was in Ihrem Fall vermutlich die Spalte id ist. Sie werden wahrscheinlich feststellen, dass ORDER BY id etwas schneller ist als ORDER BY created_at .
Primärschlüssel, insbesondere vom Ersatztyp, stellen normalerweise keine bedeutungsvollen Daten dar, abgesehen davon, dass ihre bloße Funktion darin besteht, eindeutig identifizierbare Aufzeichnungen zuzulassen. Da Daten in diesem Fall aussagekräftige Daten darstellen, die außerhalb ihrer primären Funktion Bedeutung haben, würde ich sagen, dass das Sortieren nach Daten hier ein logischerer Ansatz ist.
Bestellung nach ID-Bestellungen nach Insertion Bestellung.
Wenn Sie Anwendungsfälle haben, bei denen das Einfügen verzögert werden kann, z. B. ein Stapelprozess, müssen Sie nach created_at bestellen, um nach Zeit zu sortieren.
Beide sind akzeptabel, wenn sie Ihre Bedürfnisse erfüllen.
Tags und Links sql mysql database query-optimization