[MySQL] laatste x inserts

[Genoil]

ik moet op de homepage van een portal die ik nu aan het maken ben de laatste x toegevoegde links afdrukken. simpel, maar de manier waarop ik dat nu doe is erg traag. ik doe nu een select met een desc order op een timestamp. dat schiet niet op met een tabel die nu al bijna 3000 records heeft en er straks minstens 10.000 worden. dus ik dacht ik sla de handleiding er bij open en zie dat dat soort selects veel sneller gaat als je een index maakt van het veld waarmee je de select/order/limit doet. Dat helpt in het geval van mijn timestamp echter geen moer. doe ik iets verkeerd?

ik zat ook aan de eenvoudige mogelijkheid te denken gewoon de x laatste records uit de table te fietsen. de primary key is auto_increment, dan kan ik er toch vanuit gaan dat de laatste x records in de tabel ook de laatste x toevoegingen zijn?

edit:

nou dat laatste gaat eigenlijk geen moer sneller...

[whoami]

Genoil schreef op 24 oktober 2002 @ 21:28:
ik moet op de homepage van een portal die ik nu aan het maken ben de laatste x toegevoegde links afdrukken. simpel, maar de manier waarop ik dat nu doe is erg traag. ik doe nu een select met een desc order op een timestamp. dat schiet niet op met een tabel die nu al bijna 3000 records heeft en er straks minstens 10.000 worden. dus ik dacht ik sla de handleiding er bij open en zie dat dat soort selects veel sneller gaat als je een index maakt van het veld waarmee je de select/order/limit doet. Dat helpt in het geval van mijn timestamp echter geen moer. doe ik iets verkeerd?

Een index en hij helpt niet? Vreemd..... Ik weet eigenlijk niet of een index gebruikt wordt bij het sorteren....

ik zat ook aan de eenvoudige mogelijkheid te denken gewoon de x laatste records uit de table te fietsen. de primary key is auto_increment, dan kan ik er toch vanuit gaan dat de laatste x records in de tabel ook de laatste x toevoegingen zijn?

Hmm.... Daar zou ik nog zo zeker niet van zijn..... Stel dat je autoinc plots zijn limiet heeft bereikt (ja, dan mag je idd al heel wat records gehad hebben), wat gebeurt er dan met die autoincrement?

Wat je ook kunt doen is een extra tabelletje bijhouden met daarin telkens de 5 nieuwste links. Redundantie, i know, maar 't is wel het veiligst, en ook snel.

[Verwijderd]

Misschien moet je een 'LIMIT' meegeven aan de select zodat je niet 3000 records krijgt, maar bijv. 5?

Gauw even een startpunt: http://www.mysql.com/doc/en/LIMIT_optimisation.html

[whoami]

Verwijderd schreef op 24 oktober 2002 @ 21:35:
Misschien moet je een 'LIMIT' meegeven aan de select zodat je niet 3000 records krijgt, maar bijv. 5?

Gauw even een startpunt: http://www.mysql.com/doc/en/LIMIT_optimisation.html

Die select gaat imho/afaik toch alle records gaan ophalen, deze sorteren en dan pas de limit doen.

[whoami]

If you use LIMIT # with ORDER BY, MySQL will end the sorting as soon as it has found the first # lines instead of sorting the whole table.

* whoami vraagt zich eigenlijk af of dit wel kan.... Hij moet toch eerst alle rows sorteren vooraleer het dbms zeker kan zijn dat hij de juiste returned... ?

[Verwijderd]

whoami schreef op 24 oktober 2002 @ 21:37:

[...]


Die select gaat imho/afaik toch alle records gaan ophalen, deze sorteren en dan pas de limit doen.

Wat is dan het nut van een database limit functie als het geen verschil zou uitmaken in het aantal rijen wat terug komt, in vergelijking met als je het bijv. in PHP zou limiteren op 10

[whoami]

Verwijderd schreef op 24 oktober 2002 @ 21:40:
[...]


Wat is dan het nut van een database limit functie als het geen verschil zou uitmaken in het aantal rijen wat terug komt, in vergelijking met als je het bijv. in PHP zou limiteren op 10

Het maakt natuurlijk uit in het aantal rijen dat hij teruggeeft, maar ik heb het over of het uitmaakt in efficientie.

Stel, je hebt een tabel met 100 records. Je wilt enkel de eerste 10 records terugkrijgen, en dan eigenlijk de eerste 10 alfabetisch op naam gesorteerd bv.

Hoe kan het DBMS weten welke 10 records hij moet returnen als hij niet eerst alle 100 records sorteert?

[Verwijderd]

Hmmm...tijd dat iemand een benchmarkje opzet want nu begin ik ook te twijfelen of het allemaal uitmaakt

[whoami]

Lees nog eens een van m'n vorige posts.... Ik heb daar gequoted uit die webpage die jij neergezet hebt van MySQL...... 'k vind dat een vreemde uitspraak....

[Genoil]

ik heb er idd (uiteraard) een limit opzitten. ik zou wel ff een benchmarkje kunnen maken met en zonder. verder hebbik ook geprobeerd te sorteren op de primary key ipv de timestamp waar ik het over had, maar dat maakt nauwelijks verschil.

als dit uiteindelijk allemaal verder geen verbetering opleverd, is er natuurlijk de eenvoudige oplossing tot het aanmaken van een extra mini-tabelletje die de laatste x (x is een contstante, maar kweet layout-technisch nog ni precies hoeveel) toegevoegde records in de monstertable bijhoudt.

[edit]
ik heb ff het verschil in tijd gemeten met en zonder LIMIT. De tijd die ik gemeten heb behelst strikt de mysql_query($query), niet het fetchen. Toch duurt het ongeveer 66% langer om die query uit te voeren. Vaag...

[oja]

If you use LIMIT # with ORDER BY, MySQL will end the sorting as soon as it has found the first # lines instead of sorting the whole table.

Ja natuurlijk maakt dat wat uit! Ik weet niet precies welke sorteermethode MySQL gebruikt, maar het zal vast geen bubblesort zijn. In dat geval zou het idd niet uitmaken. Veel voor de hand liggender is dattie quicksort gebruikt, en daar flikkert ie natuurlijk na elke scheiding de helft weg zolang het aantal records in die helft groter is dan de LIMIT waarde. Die helft hoeft ie dan niet meer te doen.

[cameodski]

whoami schreef op 24 oktober 2002 @ 21:42:
Het maakt natuurlijk uit in het aantal rijen dat hij teruggeeft, maar ik heb het over of het uitmaakt in efficientie.

Stel, je hebt een tabel met 100 records. Je wilt enkel de eerste 10 records terugkrijgen, en dan eigenlijk de eerste 10 alfabetisch op naam gesorteerd bv.

Hoe kan het DBMS weten welke 10 records hij moet returnen als hij niet eerst alle 100 records sorteert?

Het is inderdaad nogal verwarrend wat daar staat.
Waarschijnlijk bedoelen ze dat dit gebeurt als er op de kolom waarop gesorteerd wordt een index ligt. Op basis van deze index kan ie dan de eerste 10 records op zoeken en vervolgens eventueel de rest van het record erbij zoeken.
Als je een complete tabel gesorteerd terug wilt krijgen, zal er vaak geen gebruik gemaakt worden van een index, omdat ie dan per record wat ie in de index tegenkomt, de rest van het record er bij moet zoeken en dat levert nogal wat schijfactiviteit op. In het geheugen sorteren is daardoor meestal sneller.

[Verwijderd]

Genoil ik las dat je primary key auto_increment is.. dus hij heeft een uniek nummer.
Je kan het hoogste (laatst toegevoegde) record opvragen.
Daar tel je x vanaf.

En dan doe je een select tussen die waarden
zoiets> select * from blaat where id > 2500 and id < 2520;

[cameodski]

Verwijderd schreef op 24 oktober 2002 @ 23:38:
Genoil ik las dat je primary key auto_increment is.. dus hij heeft een uniek nummer.
Je kan het hoogste (laatst toegevoegde) record opvragen.
Daar tel je x vanaf.

En dan doe je een select tussen die waarden
zoiets> select * from blaat where id > 2500 and id < 2520;

En hoe wil je dat doen als er tussen 2500 en 2520 bijvoorbeeld 19 records verwijderd zijn?
Of zou hier echt nooit iets verwijderd worden? Zou kunnen, maar het risico kun je niet nemen.

Genoil: heb je al eens gekeken naar het query plan/execution plan of hoe dat ding ook heten mag in MySQL? En als je nu de eerste ipv de laatste links pakt, wat gebeurt er dan? Post anders je query eens.
Mijn boerenverstand (voorzover aanwezig ) zegt me dat met een index deze query heel snel klaar moet zijn.

[Genoil]

PHP:

function KN2_HOME_GetLatestLinks($count)
{   
    $sQuery = "SELECT node.*, link.*;"; 
    $sQuery.= "FROM node LEFT JOIN link ON node.lid = link.id ";
    $sQuery.= "ORDER BY link.tsub DESC LIMIT ".$count;
    $result = KN2_DB_ProcessQuery($sQuery);
    ...
}

tis een beetje een brakke tabelstructuur van 2 jaar terug (toen ik nog dacht het handig was) vandaar het geklooi met die left join, maar daar zit/zat em wel het probleem. ORDEREN op link.id maakte het niks sneller, maar nu zie ik ineens dat het met indexen veel sneller gaat als ik ORDER op node.id ipv link.tsub...

Als ik echter van link.tsub (een TIMESTAMP(14)) een index maak, maakt het allemaal niks uit. Hoe kan dat?

[cameodski]

Ik snap toch niet echt waarom je een LEFT JOIN nodig hebt. Je hebt in de node tabel een lid (FK) zitten die naar het id (PK) verwijst van de link tabel. Dat betekent dat er nodes kunnen zijn zonder link. Op zich is dat mogelijk, maar ik dacht dat je alleen links wilde zien, dus waarom filter je dan de nodes zonder links er niet uit. Dan krijg je dus een gewone JOIN en dan denk ik dat je probleem opgelost is.

[Genoil]

cameodski schreef op 25 oktober 2002 @ 13:31:
Ik snap toch niet echt waarom je een LEFT JOIN nodig hebt. Je hebt in de node tabel een lid (FK) zitten die naar het id (PK) verwijst van de link tabel. Dat betekent dat er nodes kunnen zijn zonder link. Op zich is dat mogelijk, maar ik dacht dat je alleen links wilde zien, dus waarom filter je dan de nodes zonder links er niet uit. Dan krijg je dus een gewone JOIN en dan denk ik dat je probleem opgelost is.

Hmm je hebt gelijk. Ik heb eens wat zitten rotzooien in het begin met die joins, en heb er eigenlijk nooit wat aan veranderd, die LEFT JOIN is idd nergens goed voor.

Maar als ik nu van link.tsub een Index maakt, wordt het er echt niet sneller op...

[cameodski]

Probeer het anders eens zonder de join op node. Of misschien moet je wel link als basis nemen en node erbij joinen. Dan krijg je dus zoiets:

code:

SELECT *
FROM link
JOIN node ON node.lid = link.id
ORDER BY link.tsub
DESC LIMIT 0, 10

[Genoil]

mja die query doet het niet.

[judgem]

In PHP is het relatief eenvoudig om een x aantal entries weg te schrijven. Voorwaarde is idd wel dat de zaak gesorteerd is. Ik heb het bij mij geloof ik via een while loop gedaan..

Of wil je perse dat alles al in de MYSQL goed staat?