Hallo zusammen,
ich habe Zeitdaten die ich gerne in einer SQL Datenbank abspeichern möchte.
Hauptsächlich möchte ich immer den (zeitlich gesehen) letzten Eintrag auslesen.
Also zum Beispiel per:
[sql]SELECT * FROM timetable ORDER BY timecol DESC LIMIT 1; #(“timecol” ist die Spalte mit dem Zeitstempeln)[/sql]
Wie muss ich aber den Index der Spalte “timecol” setzten um möglichst schnell zuzugreifen?
ASC oder DESC oder ist es egal?
Besten Dank
code
ich kenne mich mit Indexen so wenig aus, dass ich das nicht beantworten kann, die Frage an sich sieht mir aber grausig aus,
an dieser Stelle würde ich schlicht den vorhandenden Standard nehmen und nicht weiter nachdenken oder größer nachlesen, wie Indexe funktionieren,
ein anderer Vorschlag, der dir aber helfen könnte, deine Query mit Sortierung vielleicht unnötig macht:
wer immer die Daten in die Tabelle schreibt, könnte
A) die Id des Eintrags an eine feste Position in einer zweiten Tabelle schreiben
(dann Abfrage nach Eintrag mit genauer Id, ohne Sortierung, aber vielleicht Auffinden immer noch von guten Index, nun eben auf Id-Spalte, abhängig)
oder
B) gleich die gesamten Daten in einer zweiten Tabelle schreiben, Kopie des Eintrags, immer nur den aktuellsten, überschrieben,
konkurrenzlos schnell zu finden, dafür mehr Aufwand beim Speichern…
Ohne jetzt eine Quelle für die Aussage vorweisen zu können, wage ich zu behaupten, dass das bei einem normalen Index keinen Unterschied macht. Mit einem “normalen” Index meine ich einen Binärbaum als Index, wie ihn MySQL standardmäßig verwendet. Wie man einen Binärbaum auf- oder absteigend sortiert, kann ich mir nicht vorstellen.
Der Zugriff auf das größe Element erfolgt also genauso schnell, wie wenn du das Element mittels Primärschlüssel geladen hättest.
Es kann übrigens sein, dass (je nach verwendetem Datentyp, ein TIMESTAMP wäre OK) der Index ziemlich groß wird und nur relativ langsam aufgebaut werden kann, wenn du Elemente einfügst.
gibt es nicht vielleicht eine autoincrement id spalte als primärschlüssel? dann wär die situation ganz anders…
Könntest du das ausführen?
bringt dir soweit nichts, weil es könnte ja sein dass die IDs zyklisch sind und du einfach irgendwann wieder am Anfang bist (wenn die IDs noch frei sind)
Ich denke es ist egal ob auf oder absteigend sortiert, weil sortiert werden muss so oder so. Und selbst wenn es einen Unterschied machen sollte, dann wird das System, wenn es gut ist, merken dass die andere Richtung schneller ist und einfach nur das Ergebnis vertauschen
[QUOTE=EagleEye]bringt dir soweit nichts, weil es könnte ja sein dass die IDs zyklisch sind und du einfach irgendwann wieder am Anfang bist (wenn die IDs noch frei sind)
Ich denke es ist egal ob auf oder absteigend sortiert, weil sortiert werden muss so oder so. Und selbst wenn es einen Unterschied machen sollte, dann wird das System, wenn es gut ist, merken dass die andere Richtung schneller ist und einfach nur das Ergebnis vertauschen[/QUOTE]
ginge schon, mit einer autoincrement long würde das ziemlich lange dauern bis da irgendwas zyklisch wird - und ein solcher primärschlüssel wäre automatisch ein index, und “der letzte Datensatz” wäre auch der letzte physikalische Datensatz -
Der physikalisch letzte Datensatz bleibt es so oder so. Ich kann mir nicht vorstellen, dass es einen Unterschied macht, ob man nun den Primärschlüssel oder einen TIMESTAMP als Index verwendet. Denn das, was im Hintergrund abläuft ist doch in beiden Fällen das Gleiche: es wird der letzte Eintrag aus einem sortierten Index gewählt und anhand dessen der passende Datensatz ausgelesen.
Dass ich es mir nicht vorstellen kann, heißt natürlich noch lange nicht, dass es nicht doch einen Laufzeitunterschied geben mag. Das ist sicherlich dann auch Anbieterspezifisch.