MySQL Query's && ORDER BY

[Glock]

Aan de hand van een projectje waarmee ik bezig ben ik wat gaan klooien met MySQL, zo is het zo dat MySQL blijkt alles standaard te sorteren op volgorde waarop ze zijn ingevoegd. Ook na een UPDATE. Ik heb de ORDER BY over m'n veld post_id staan om te zorgen dat ze in de juiste volgorde eruit komen, terwijl (tot zover ik heb gemerkt) ze standaard in dezelfde volgorde naar buiten komen.

Nu is mijn vraag (en nee, heb dit nerges kunnen vinden), kan dit fout gaan doordat MySQL op een of andere manier ze niet meer zo sorteerd? Of is het in dit mogelijk om met een gerust hart de ORDER BY statment weg te laten?

Voor de duidelijkheid: het weglaten van ORDER BY scheelt factor 30 in de tijd. Dit heb ik getest op een DB met 20.000 waardes waarvan er 10.000 geselecteerd worden met een LIMIT van 0, 25. Het desbetreffende veld waar de ORDER BY bij staat is een INT 64 veld met auto_increment. Dit veld heeft (uiteraard) een index.

Dit zijn de query's waarmee getest is:

code:

SELECT p.post_time, p.post_text , u.username,
u.user_sig, u.user_title, u.user_level
FROM posts p
LEFT JOIN users u ON p.post_user = u.user_id
WHERE p.post_topic = '$topic_id'
LIMIT '$start', '$tpp'

code:

SELECT p.post_time, p.post_text , u.username,
u.user_sig, u.user_title, u.user_level
FROM posts p
LEFT JOIN users u ON p.post_user = u.user_id
WHERE p.post_topic = '$topic_id'
ORDER BY p.post_id
LIMIT '$start', '$tpp'

Edit: Typo.
Edit2: Ter info: De draaiende MySQL is 3.23.47 die binnenkort word upgedate naar MySQL 4 (Laatste WIN32 Versie)
Edit3: Foutje in gedachtengang, verkeerde veld in verhaal getypt nu maar ff verbeterd (maakt niks uit voor het verhaal btw)

[Verwijderd]

Leg je wel een index op de velden die je gebruikt in je ORDER BY?

[Glock]

Op donderdag 02 mei 2002 14:27 schreef gotbert het volgende:
Leg je wel een index op de velden die je gebruikt in je ORDER BY?

Dit veld heeft (uiteraard) een index.

[whoami]

Misschien kun je even in een manual of andere spec kijken van MySQL waar hij standaard op sorteert.
Het is alleszins niet 'defensief programmeren' als je die ORDER BY eruithaalt als je wilt dat die records op een bepaald veld gesorteerd worden en als je ervan uitgaat dat MySQL toevallig automatisch op dat veld sorteert. Wie zegt dat dat in een volgende versie van MySQL nog het geval gaat zijn?

[Crazy D]

Op donderdag 02 mei 2002 14:21 schreef Glock het volgende:
De Tabel waaruit ik de waardes pluk heeft ook een veld 'tijd', in principe gooi ik over de tijd een ORDER BY.

In principe misschien wel, maar nu even niet? Tenzij ik heel erg zit te zie ik geen order by tijd, alleen op postid.

En die standaart sorteervolgorde kan puur toeval zijn. Bij mijn weten voegen een hoop db's in principe gewoon een record "aan het eind" toe, tenzij er tussen in een record verwijdert is. Iig da's mijn ervaring, en het is absoluut iets waar je _niet_ op kunt/moet/mag/wilt vertrouwen.

[Glock]

Op donderdag 02 mei 2002 14:35 schreef Crazy_D het volgende:

Whoops, typo, ik sorteer hem idd op id, eerst sorteerde ik hem op tijd maar daar zat voor de funtionaliteit wat nadelen aan dus ging ik hem op id sorteren die deze nadelen niet had voor de resultataten die ik moet hebben (voor de duidelijkheid, het is dus een forum )

En wat jij zegt, of het nou wel of geen toeval is, dat probeer ik hier dus te achterhalen door deze vraag te stellen, heb nml nog niks hierover kunnen vinden.

Op donderdag 02 mei 2002 14:33 schreef whoami het volgende:

Dit is dus het probleem, dit kan ik nergens vinden
Als iemand anders dit wel heeft kunnen vinden, ik zou je heel dankbaar zijn voor de linkd

[Crazy D]

Op donderdag 02 mei 2002 14:40 schreef Glock het volgende:
En wat jij zegt, of het nou wel of geen toeval is, dat probeer ik hier dus te achterhalen door deze vraag te stellen, heb nml nog niks hierover kunnen vinden.

Ik zou mijn tijd niet verdoen aan het zoeken naar info over de default sortering van een db, en gewoon altijd ervoor zorgen dat de data die je wilt hebben er op de juiste manier (via een query met order by) eruit komt, dan weet je zeker dat het altijd goed gaat.
En wat whoami ook zegt, als er in een nieuwe versie opeens die default sortering eruit wordt gehaald, ben jij de l*l.

[Glock]

Op donderdag 02 mei 2002 15:46 schreef Crazy_D het volgende:

[..]

Ik zou mijn tijd niet verdoen aan het zoeken naar info over de default sortering van een db, en gewoon altijd ervoor zorgen dat de data die je wilt hebben er op de juiste manier (via een query met order by) eruit komt, dan weet je zeker dat het altijd goed gaat.
En wat whoami ook zegt, als er in een nieuwe versie opeens die default sortering eruit wordt gehaald, ben jij de l*l.

nou, we hebben nu dus net mysql 4 met innodb draaien, alleen deze keer is zonder order by de tijd nog hetzelfde alleen met order by is de tijd deze keer met factor 85 toegenomen... ik vind dit wel heel errug veel
dus ik ga nog maar ff verder uitzoeken waar die op blijft hangen of dat ik gewoon met iemand loop samen te werken die mysql niet kan installeren

[whoami]

Het is wel logisch dat een SELECT met ORDER BY langer duurt dan een SELECT zonder ORDER BY.

Maar een factor 85 is wel veel.

[eborn]

Je mag er NOOIT vanuit gaan dat MySQL sorteert op volgorde van binnenkomst. Dit gaat namelijk al fout zodra je ooit een record verwijderd hebt. Het volgende record wordt dan namelijk daar ingevoegd. Dus trust me, je hebt de ORDER BY nodig

[Crazy D]

Op donderdag 02 mei 2002 16:28 schreef Glock het volgende:
nou, we hebben nu dus net mysql 4 met innodb draaien, alleen deze keer is zonder order by de tijd nog hetzelfde alleen met order by is de tijd deze keer met factor 85 toegenomen... ik vind dit wel heel errug veel

Index?

[whoami]

Op vrijdag 03 mei 2002 11:41 schreef Crazy_D het volgende:

[..]

Index?

Hij zegt toch dat er een op ligt.

[leonardo1504]

Lijkt me optimalisatie probleem. BTW: Een SQL database is altijd onge-ordered, dat wil zeggen dat er wel een fysieke ordering is, maar die kan veranderen als je transacties doet. Een ORDER BY is altijd minder efficient dan een unordered query, maar een factor 30 lijkt me wat veel. Een join met een order by kan wel eens heel anders geevalueerd worden dan zonder order by. Is je order-by criterium uniek ?? dat kan ook schelen.

[whoami]

Heb je zo geen tooltje die het execution path ofzo van uw query gaat gaan loggen? Welke indexen hij gebruikt enzo en op welk veld hij geen index gebruikt.

[WouZz]

Op vrijdag 03 mei 2002 11:57 schreef whoami het volgende:
Heb je zo geen tooltje die het execution path ofzo van uw query gaat gaan loggen? Welke indexen hij gebruikt enzo en op welk veld hij geen index gebruikt.

check EXPLAIN ff..

[ACM]

Op vrijdag 03 mei 2002 11:51 schreef leonardo1504 het volgende:
BTW: Een SQL database is altijd onge-ordered, dat wil zeggen dat er wel een fysieke ordering is, maar die kan veranderen als je transacties doet.

Mja, MySQL doet dus wel standaard aan ordering lijkt het. Of het slaat de data ordened (op prim.key) op.

[bluewarlord]

Het is allemaal best wel simpel als je de docs leest :
http://www.mysql.org/doc/S/E/SELECT_speed.html

Je kunt mysql vertellen om een table op de schijf in de goede volgorde te sorteren. Het beste lijkt me om dit in een cron jobje elke nacht te doen.

[leonardo1504]

Mja, MySQL doet dus wel standaard aan ordering lijkt het. Of het slaat de data ordened (op prim.key) op.

JA geordend op fysiek niveau, dus op de volgorde waarop de rijen ge-insert zijn. Als je dan een rij verwijderd (pk=50 max(pk)=200) en je voegt hem weer toe, sluit ie achteraan aan. dan krijg je dus: 197,198,199,200,50,.... etc. Geloof me, (relationele) SQL is in principe ongeorderd.

[ACM]

Op vrijdag 03 mei 2002 12:12 schreef bluewarlord het volgende:
Het is allemaal best wel simpel als je de docs leest :

En nu met innodb?
* ACM is daar wel in geinteresseerd.