[mysql] letzten 10 einträge ASC-sortiert?

Bububoomt

Bububoomt

ohne Vertrauen
ID: 10361
L
28 April 2006
19.666
769
Gibt es ne simple möglichkeit (mit einer Abfrage) sowas zu lösen?

also die letzten 10 einträge (wobei es ne Bedinung gibt, z.b. BildID=10) in ASC auszugeben?

also sowas mit limit 50,10 ist mir klar, aber da müßte ich vorher abfragen wieviel es insgesamt gibt.

Wäre ja kein Problem, aber wenn es was leichteres bzw. effizienteres gibt, wieso nciht das nutzen?
 
SELECT COUNT (*) FROM table

sollte performanter sein, als eine komplette Abfrage, bei der man die Ergebniszeilen zählt.
 
Sofern die BildID eine fortlaufende ID ist, also das neueste Bild immer die höchste ID hat dann würd ich das wie folgt machen:

Code: 
SELECT * FROM table ORDER BY BildID DESC LIMIT 10
 
ice-breaker schrieb:
die letzten 10 Einträge in ASC sind die ersten 10 in DESC ;)
musste dann eben noch in der Anwendung invertieren, dürfte aber schneller sein, als nen SubSelect



geht aber nicht mit Bedingungen ;)
Zum Vergrößern anklicken....

Ja ja, mir klar wenn ich desc limit 10 mache, das ich das dann habe, nur will ich das ergebnis in ASC.

Also das das letzte dann auch als letztes und net erstes ist.

Also geht um Kommentare zu Bildern

Die Bedinung ist die Bildid.

quasi
Select kommentar from kommentare where bildid=xyz imit 10

(da ist noch ein Join drin um den User herauszufinden)

was wäre den wohl von der performance also besser??

Erst die Anzahl auslesen und dann mit limit arbeiten, oder halt per desc auslesen, erst in array einlesen und dann hal rückwärts ausgeben?
 
bei kommentaren ist ja eh immer alles seitenweise von daher brauchst du doch nur ein
ORDER BY `sonstwas` DESC 50,10 als Beispiel
 
Du könntest das notfalls alles in einen Array packen und so dann verarbeiten:
PHP: 
//Kommentare in Variable $commencts, die noch "falsch herum" sind
$commencts = mysql_.....
//Kommentarreihenfolge umdrehen
$comments_new = array_reverse($commets);
unset($comments);
//Index wiederherstellen
foreach($comments_new as $value){
    $comments[] = $value;
}

Aber ob das umbedingt Performanceschonender ist, kann ich dir auch nicht sagen ;)
 
Nein momentan sind es einfach nur die Letzten 10 Einträge immer, ohne Blättern (naja sind eh weniger einträge)

Bisher hatte ich auch desc 10, nur ist mir nun aufgefallen, das ja doof, wenn da folgendes z.b. steht:


zzz: ihr habt beide recht
xxx: Da hast du verdammt recht
xyz: Das ja ein nettes Mädel

wäre ja so sinnvoller:

xyz: Das ja ein nettes Mädel
xxx: Da hast du verdammt recht
zzz: ihr habt beide recht

sonst muß man ja von unten nach oben lesen. Nun verständlicher was ich meine??

deswegen würde ich gern das desc 10 dann einmal in asc sortiert haben wollen.

*edit*
@flaschenkind, ja das ja die frage ist das besser, oder doch erst anzahl abfragen und dann mit limit arbeiten!?

bzw. reverse brauch ich gar net, mit ner forschleife einfah rückwärts das array durchlaufen, aber was da wieder schneller? for oder doch reverse und foreach!?!?!?
 
Zuletzt bearbeitet:
Habs getesten und die 2 Querys scheinen langsamer zu sein, bei 50 durchläufen dauerte es im schnitt 0,026 Sek. Mit dem for nur 0,016 sek.

Also mach ichs mit for auf jedenfall.
 
Bububoomt schrieb:
Habs getesten und die 2 Querys scheinen langsamer zu sein, bei 50 durchläufen dauerte es im schnitt 0,026 Sek. Mit dem for nur 0,016 sek.

Also mach ichs mit for auf jedenfall.
Zum Vergrößern anklicken....

das ist doch immer je nach Serverauslastung unterschiedlich :roll:
Die for-Schleife ist CPU-lastig und die Datenbank-Variante IO-lastig.
Nun ist die Frage von was du bei Peaks deutlich mehr Reserven hast, und da gewinnt die CPU um ein tausendfaches
 
also ich kann sagen, das die Forschleife gewinnt, denn mein Server ist momentan eher Überlastet, und als ichs vorhin getestet hatte, habe ich dabei auch den Server beobachtet (er war mehr als ausgelastet). Deswegen kommt ja auch bald nen Umzug auf nen besseren.

Habs ja auch mehrfach getestet und bei nur gerade mal 3 von 40-50 Test (mit 50er schleife) hat die DB abfrage gewonnen. Habs immer abwechelnd gemacht.
 
ice-breaker schrieb:
das ist doch immer je nach Serverauslastung unterschiedlich :roll:
Die for-Schleife ist CPU-lastig und die Datenbank-Variante IO-lastig.
Nun ist die Frage von was du bei Peaks deutlich mehr Reserven hast, und da gewinnt die CPU um ein tausendfaches
Zum Vergrößern anklicken....

Eine Datenbankabfrage verursacht natürlich auch CPU-Last und zwar nicht zu knapp. Ist ja nicht so dass der Prozessor die Datenbank einmal anhaut und schon purzeln die gewünschten Datensätze heraus. In diesem Fall muss jeder Datensatz angeschaut und die Bedingung überprüft werden. Krasser wird es, wenn ein kartesisches Produkt gebildet werden muss, das ist sehr rechenintensiv und frisst zusätzlich noch eine Menge Platz.
Da normalerweise die kompletten Daten gecached werden, sollte es erst dann zu einem Problem kommen, wenn die Tabelle so groß ist, dass sie nicht in einem Stück in den RAM passt. Da bei ihm aber eine Query weniger als 0,5 Millisekunden dauert, wird das wohl nicht der Fall sein.
 
Ja, momentan ist die DB fast leer, ich werde aber es beobachten, wie es aussieht, wenn sie sich mit der Zeit füllt. Vorallem, wie es dann auf dem neuen Server aussieht!?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben