Am schnellsten die letzten 100 Datensätze aus ner DB laden?

[AlexII]

Hallo,

ich möchte aus einer DB am schnellsten die letzten 100 Datensätze holen. Ich kam auf diese Lösung, gibt's bessere Ideen?

Delphi-Quellcode:

SELECT knr FROM tbteilnehmer ORDER BY id_teilnehmer DESC LIMIT 100

Wird da nicht erst sortiert? Das kann doch unter Umständen lange dauern, oder?

[DeddyH]

Definiere "die letzten 100".

[baumina]

Wenn id_teilnehmer indiziert ist, muss er nicht sortieren, sondern geht über den Index. Dann müsste das so recht schnell gehen.

[AlexII]

Zitat:

Zitat von baumina (Beitrag 1285804)

Wenn id_teilnehmer indiziert ist, muss er nicht sortieren, sondern geht über den Index. Dann müsste das so recht schnell gehen.

id_teilnehmer ist der PK, dieser wird automatisch indiziert, oder?

[mkinzler]

Ja. Bei einem PK wir automatisch ein Index angelegt

[tsteinmaurer]

Ob dann dieser automatisch erstelle Index für einen PL bei einem DESC verwendet werden kann ist DBMS-spezifisch.

[pertzschc]

Ist das hier ein Doppelpost von hier?
Hast Du die Lösung dort bereits verstanden und umgesetzt?

Viele Grüße,
Christoph

[AlexII]

Zitat:

Zitat von pertzschc (Beitrag 1285810)

Ist das hier ein Doppelpost von hier?
Hast Du die Lösung dort bereits verstanden und umgesetzt?

Viele Grüße,
Christoph

Nein das ist kein Doppelpost!

[mkinzler]

Das könnte man schon als recht ähnlich ansehen ( die letzten x mit x= 1 vs x = 100)

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1285813)

Das könnte man schon als recht ähnlich ansehen ( die letzten x mit x= 1 vs x = 100)

Das schon, aber ich suchte nach einer besseren Lösung.

[p80286]

Zitat:

Zitat von AlexII (Beitrag 1285817)

Das schon, aber ich suchte nach einer besseren Lösung.

Und was gefällt Dir daran nicht?

Gruß
K-H

[danielmagin]

Zitat:

Zitat von AlexII (Beitrag 1285800)

Hallo,

ich möchte aus einer DB am schnellsten die letzten 100 Datensätze holen. Ich kam auf diese Lösung, gibt's bessere Ideen?

Delphi-Quellcode:

SELECT knr FROM tbteilnehmer ORDER BY id_teilnehmer DESC LIMIT 100

Wird da nicht erst sortiert? Das kann doch unter Umständen lange dauern, oder?

also bei fast allen DB's ist der PK immer ein Aufsteigender Index (ASC)

somit erstelle dir ein INDEX auf das PK Feld als DESC index, somit muss er nicht natural laufen

dann klappt deine Anfrage immer sehr schnell.

[AlexII]

[QUOTE=danielmagin;1285879]

Zitat:

Zitat von AlexII (Beitrag 1285800)

Hallo,

ich möchte aus einer DB am schnellsten die letzten 100 Datensätze holen. Ich kam auf diese Lösung, gibt's bessere Ideen?

Delphi-Quellcode:

SELECT knr FROM tbteilnehmer ORDER BY id_teilnehmer DESC LIMIT 100

somit erstelle dir ein INDEX auf das PK Feld als DESC index, somit muss er nicht natural laufen

Ok... und wie mache ich das?

[mkinzler]

Indem Du einen Index auf id_teilnehmer mit absteigender Sortierung erstellst. Geht einfach im Admintool oder mit SQL Create INDEX ...

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1285883)

Indem Du einen Index auf id_teilnehmer mit absteigender Sortierung erstellst. Geht einfach im Admintool oder mit SQL Create INDEX ...

Das heiß, dass in meiner Abfrage erst absteigend sortiert wird und nicht vorher?

Delphi-Quellcode:

SELECT knr FROM tbteilnehmer ORDER BY id_teilnehmer DESC LIMIT 100

[DeddyH]

Wie, "vorher"?

[AlexII]

Zitat:

Zitat von DeddyH (Beitrag 1285887)

Wie, "vorher"?

Ich meine muss ich vorher (nach Programmstart) meine IDs mit DESC sortieren und danach

Delphi-Quellcode:

SELECT knr FROM tbteilnehmer ORDER BY id_teilnehmer DESC LIMIT 100

aufrufen? Damit die Werte vor der Abfrage schon DESC sortiert sind, oder ich lasse meine select Abfrage so wie sie jetzt ist und fertig?

[mkinzler]

Wenn du aufsteigend sortierest, witrd der ASC INDEX verwendet und wenn du absteigend sortierst der DESC INDEX, falls vorhanden, sonst wird ein full table scan gemacht -> langsam.

[DeddyH]

Die Daten in der Tabelle liegen in irgendeiner undefinierten Reihenfolge vor, sortiert werden kann also nur bei der Abfrage. Und danach ändert sich die Reihenfolge innerhalb der Tabelle auch nicht, wäre ja auch völliger Blödsinn, da wäre der Server ja beinahe nur noch mit Sortieren beschäftigt. Aus diesem Grund musst Du die Sortierung in Deinem Statement angeben, es gibt also kein "vorher".

[edit] Nachtrag: Und dafür gib es ja die Indizes, die sind sortiert und werden auch ggf. aktualisiert, wenn sich Daten ändern. [/edit]

[AlexII]

Zitat:

Zitat von DeddyH (Beitrag 1285894)

Die Daten in der Tabelle liegen in irgendeiner undefinierten Reihenfolge vor, sortiert werden kann also nur bei der Abfrage. Und danach ändert sich die Reihenfolge innerhalb der Tabelle auch nicht, wäre ja auch völliger Blödsinn, da wäre der Server ja beinahe nur noch mit Sortieren beschäftigt. Aus diesem Grund musst Du die Sortierung in Deinem Statement angeben, es gibt also kein "vorher".

Aber der PK wird doch von der DB immer automatisch indexiert wurde hier gesagt... jetzt verstehe ich nix mehr. :roteyes:

[DeddyH]

Siehe mein Edit.

[mkinzler]

Ja, es wird ein aufsteigender INDEX erzeugt, den der wird normalerweise verwendet. Willst Du eine abweichende Sortierung ( also absteigend) musst Du selber für einen passenden INDEX sorgen.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1285898)

Ja, es wird ein aufsteigender INDEX erzeugt, den der wird normalerweise verwendet. Willst Du eine abweichende Sortierung ( also absteigend) musst Du selber für einen passenden INDEX sorgen.

Und wenn ich dafür nicht sorge, kann meine select-Abfrage bei sehr vielen Datensätzen ewig dauern?

[mkinzler]

Ja, den wenn kein INDEX vorhanden ist macht er einen full table scan, d.h. er sucht direkt in der Tabelle, in der die Datensätze unsortiert in der Reihenfolge des Einfügens geschrieben sind.

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1285900)

Ja, den wenn kein INDEX vorhanden ist macht er einen full table scan, d.h. er sucht direkt in der Tabelle, in der die Datensätze unsortiert in der Reihenfolge des Einfügens geschrieben sind.

Hm... schade, aber gut, man muss damit leben.

[vagtler]

Zitat:

Zitat von AlexII (Beitrag 1285908)

[...] Hm... schade, aber gut, man muss damit leben.

Nein, muss man nicht (s.o.).

[mkinzler]

Den man kann einfach einen weiteren Index anlegen

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1285910)

Den man kann einfach einen weiteren Index anlegen

Ein Attribut mit zwei Indexen?

[Dejan Vu]

Yo, und?