[mysql] mysql kan niet achterstevoren sorteren

[chem]

dit GELOOF je toch niet.
Stel we hebben een table van 16 miljoen records, met oa. een text blob en int(10) uns. UNIX timestamps.

Nu willen we echt iets heel moeilijks. Ja, het is even wennen en het komt niet vaak voor in de Wondere Wereld der Databases: we willen de 30 laatste geplaatste records hebben.
Ja, ik weet het dit is allemaal zeer gevorderd en de query is vrij complex ook:

select recordid, stamp
from table
order by stamp DESC
limit 30;

Nu doet mysql er (met index op stamp, of recordid/stamp of vv.; het maakt niks uit) ruim 3 seconden over deze toch wel erg pittige vraag

Als we de query omdraaien:

select recordid, stamp
from table
order by stamp ASC
limit 30;

dan verwent mysql ons met een tijd van 0.02 seconde.

WAAROM?
omdat mysql 3.23.x zo compleet KUT is, dat hij niet 'achterstevoren' kan sorteren op een index. dus.
Zie onder andere deze en deze discussies.

De enige oplossing is een inverted timestamp vermelden (dus jaar 2038 - timestamp).
Wie heeft dit nog meer opgemerkt en nog liever; opgelost?

[Anders]

Is inderdaad, ehm, knudde ja. Als je met twee queries werkt, eentje met count( en de andere LIMIT count-30, 30? Er vanuitgaande dat er in de tussentijd niks bij wordt gegooid, als dat zo is gaat deze vlieger niet op natuurlijk

[chem]

Helaas, dat is geen opossing...
enige oplossing voor alsnog is de 2e column toevoegen...

[mulder]

Dom stom GRATIS programma, wat denken ze wel niet, als je het zelf had gemaakt was 10000 keer beter. Ik bedoel een table van 16 miljoen records!

[Verwijderd]

*let op... dit is *geen* flame*

Dom stom GRATIS programma, wat denken ze wel niet...

Helemaal mee eens dat je een gegeven paard niet in de bek moet kijken, maar de Open Source Community (met 3 hoofdletters) heeft altijd zo'n grote muil dat alles Open Source zo Veel Beter is dat je dan dus inderdaad dit soort reakties gaat krijgen.

Technisch gezien is er eigenlijk geen enkele goede reden te noemen waarom achterstevoren sorteren op een index langer zou moeten duren, dus mysql is wel degelijk dom

16 miljoen records is trouwens niet eens zo heel extreem veel.

[chem]

16 miljoen is idd zeker niet zo veel. Ik heb het ook met 4 miljoen getest en het maakt geen moer uit.

Of het gratis is of niet; er word idd gepretendeerd dat het de 'snelste' is etc.; terwijl 1 van de meest voorkomende queries (iig op veel sites vaak voorkomend) niet optimaal uitgevoerd kan worden...

[mulder]

OK, maar het is een product dat door een community ontwikkelt word. Roepen dat MySQL compleet kut is, duh! Die limit functie schijnt bv niet eens in MsSQL te zitten, daar kun je alleen top en/of bottom opvragen.

[Grum]

Qlone: Technisch gezien is er eigenlijk geen enkele goede reden te noemen waarom achterstevoren sorteren op een index langer zou moeten duren, dus mysql is wel degelijk dom


Tis altijd fijn om te weten dat er hier mensen rondlopen die mee ontwikkelen aan mysql ... hoe kan je anders weten dat er geen technische reden voor is en als er dan geen technische reden voor je en jij zo hard meewerkt met de development van mysql .. waarom los je het dan niet op

Kort gezegt .. lees de source, leer de source, snap waarom het en probleem is en als jij dat geen probleem vind .. [b]FIX HET DAN[/b], maar ondertussen .. stop met zeiken want het is en blijft gratis en als je dat niet bevalt .. GEBRUIK HET DAN GEWOON NIET en betaal jezelf fijn scheef aan een MSSQL/Oracle ofzo..

Tnx ..

[Bobco]

Op vrijdag 12 april 2002 10:32 schreef Qlone het volgende:
[..]

Helemaal mee eens dat je een gegeven paard niet in de bek moet kijken, maar de Open Source Community (met 3 hoofdletters) heeft altijd zo'n grote muil dat alles Open Source zo Veel Beter is dat je dan dus inderdaad dit soort reakties gaat krijgen.

Hmm, ik denk dat je nu even de veronderstelde superioriteit van de manier van ontwikkelen verwart met de kwaliteit van de produkten die opgeleverd worden met deze manier van ontwikkelen.

Closed en open source kunnen beide in kwaliteit varieren van volslagen debiel tot absoluut brilliant. Helaas valt bijna alles in die grije categorie tussen deze twee uitersten.

[justmental]

Op vrijdag 12 april 2002 10:34 schreef chem het volgende:
Of het gratis is of niet; er word idd gepretendeerd dat het de 'snelste' is etc.; terwijl 1 van de meest voorkomende queries (iig op veel sites vaak voorkomend) niet optimaal uitgevoerd kan worden...

Nou, nou, rustig maar

Die extra kolom opnemen is toch een oplossing.
En anders Oracle gaan gebruiken, die kan indexen wel descending sorteren.

[chem]

Op vrijdag 12 april 2002 10:37 schreef justmental het volgende:

[..]

Nou, nou, rustig maar

Die extra kolom opnemen is toch een oplossing.
En anders Oracle gaan gebruiken, die kan indexen wel descending sorteren.

nou ja, 't is vrij frustrerend om hier na uren kloten pas achter te komen.

MySQL 4 heeft het inmiddels opgelost; maar ja het moet op 3.23.x draaien dus daar heb ik weinig aan.

Vooralsnpg dus de extra kolom totdat mysql 4 uitkomt...

[justmental]

Op vrijdag 12 april 2002 10:39 schreef chem het volgende:
nou ja, 't is vrij frustrerend om hier na uren kloten pas achter te komen.

MySQL 4 heeft het inmiddels opgelost; maar ja het moet op 3.23.x draaien dus daar heb ik weinig aan.

Vooralsnpg dus de extra kolom totdat mysql 4 uitkomt...

Heb je iets van triggers om de kolom automagisch te laten vullen?
Dan is het toch niet zoveel werk?

_{Kun je ff je topictitel verfrissen?}

[chem]

triggers in mysql?
nee, 't zal bij elke update moeten gebeuren (wat gelukkig niet moeilijk zal zijn in m'n ontwerp)

[Verwijderd]

Hmm, ik denk dat je nu even de veronderstelde superioriteit van de manier van ontwikkelen verwart met de kwaliteit van de produkten die opgeleverd worden met deze manier van ontwikkelen.

Bewust in dit geval... Had een tijdje terug een nogal felle discussie met een nogal fanatieke Open Source aanhanger die 't zelfde deed, en die is niet de enige. Hmm... dat moet ik dan vast waar gaan maken met een URL. Zou slashdot.org volstaan?

[bartvb]

Meen me vaag te herinneren dat we een tijdje gelden ook tegen zoiets aanliepen, heb er verder niet veel achter gezocht, die links van je zijn dus erg nuttig

dacht dat we nu niet sorteren op timestamp maar we pakken gewoon de laatste ID's van de autoincrement kolom. Dat ging dacht ik wel op een normale snelheid..

[chem]

ja, op de PK sorteren gaat vaak wel goed; maar dat is dus vaak incorrect (aangezien je ook bv. de laatste wijzigingen wil pakken; waardoor je dus in de knoop komt)