[MySQL] Uitvoeren query teveel resultaten

[teun-v]

Het geval is dat tijdens het maken van een php script liepen we tegen het volgende probleem aan. Tijdens het afvragen van een query loopt de server (SUSE Enterprise 9.3 dual xeon 3.0 ghz 4gb intern) volledig "vast". Opzoek na de oorzaak bleek de query teveel resultaten op te vragen waardoor de MySQL demon teveel resources nam, als resultaat een server die totaal onbereikbaar is.

Stel je hebt een database met vijf tabellen (a, b, c, d, e) en een aantal records, 3 per tabel, waar bij de primary key van alle records in de dieverse tabellen gelijk is. Na het uitvoeren van de volgende query:

SQL:

SELECT * 
FROM a, b, c, d, e 
WHERE a.id = b.id 
AND b.id = c.id 
AND c.id = d.id 
AND d.id = e.id;

zijn er dus 3 resultaten. Nu zijn wij er achter gekomen dat het mogelijk is de volgende query uit te voeren:

SQL:

SELECT *
FROM a, b, c, d, e;

Hier uit komen 243 resultaten dit zijn alle mogelijke kombinaties van de verschillende records. Echter verwachten wij een foutmelding of maximaal 3 resultaten.

Nu was het eerste wat er in mij opkwam, het is een bug. Echter hoor ik van alle kanten dat dit gewoon een valide query is. Ik zou echter niets kunnen verzinen waarom je deze query zal uitvoeren. Ik ben gekomen tot de bovenstaande query door het orgineel te vereenvoudigen waar ik een fout met een OR statment heb gemaakt.

Als je dit met tabellen doet van 200+ records dan loopt dus je server "vast" het maakt verder niet uit of je hiervoor MySQL 4.* of 5.* gebruikt hierbij hebben we gebruik gemaakt van een standaard configuratie en zowel Linux als ook Windows varianten hebben hier last van.

Nu mijnvraag: Waarom doet MySQL dit zo? Of mag ik dit beschouwen als bug in MySQL?

[Pannenkoekkie]

243 = 3x3x3x3x3

Voor ieder record in Iedere tabel zal in dit geval SQL (maar ieder ander pakket ook), de gegevens aan-elkaar plakken (dus 3x3x3x3x3).

Conclusie: je zal een Join moeten definieren, beetje google of maak een simpel Access DB'tje met daarin vergelijkbare situatie, ga dan met Query's stoeien, en copy de SQL-Statement.

[ Voor 69% gewijzigd door Pannenkoekkie op 15-03-2006 12:46 . Reden: Erg kort door de bocht ]

[stimpie79]

je vraagt alle mogelijke combinaties? MySQL probeert deze te geven...

wanneer je probeert gegevens op te halen uit verschillende tabellen zonder gebruik van joins,
bekom je een 'Cartesiaans product'


zolang er maar een klein aantal mogelijkheden zijn (243 bvb), zal dit geen probleem opleveren,
wanneer er echter te veel mogelijkheden komen, zal MySQL hier inderdaad waarschijnlijk op "crashen": time-out, buffer vol, ...

==> er zijn dan verschillende foutmeldingen mogelijk, of gewoon een hangende MySQL als gevolg..


edit: ik moet sneller leren typen

[ Voor 8% gewijzigd door stimpie79 op 15-03-2006 12:49 ]

[teun-v]

Zover was ik ook al, echter door een heele dome fout van mij ik dus wel op deze manier een tijdens het testen een server op z'n gat weten te krijgen in plaats van een leuke foutmelding.

stimpie79 schreef op woensdag 15 maart 2006 @ 12:48:
...
edit: ik moet sneller leren typen

Dat moet ik ook

[ Voor 35% gewijzigd door teun-v op 15-03-2006 12:52 ]

[Pannenkoekkie]

teun-v schreef op woensdag 15 maart 2006 @ 12:50:
In plaats van een leuke foutmelding

Waar geen fout is, geen melding.

[teun-v]

Pannenkoekkie schreef op woensdag 15 maart 2006 @ 12:52:
[...]


Waar geen fout is, geen melding.

Klopt, Maar waarom zou het mogelijk moetten zijn om een dergelijke query doorgang te laten vinden door MySQL. Het laat de server hangen bij domme fouten die ik wel eens maak bijvoorbeeld haakjes vergeten en dergelijke.

Edit:
Op link heb ik gevonden wat er wordt bedoelt met 'Cartesiaans product' het is exact de fout die ik heb gemaakt. Maar dan nog begrijp ik niet waarom dit mogelijk zou moeten zijn.

[ Voor 26% gewijzigd door teun-v op 15-03-2006 13:08 ]

[Raku]

teun-v schreef op woensdag 15 maart 2006 @ 12:57:
[...]

Klopt, Maar waarom zou het mogelijk moetten zijn om een dergelijke query doorgang te laten vinden door MySQL. Het laat de server hangen bij domme fouten die ik wel eens maak bijvoorbeeld haakjes vergeten en dergelijke.

Edit:
Op link heb ik gevonden wat er wordt bedoelt met 'Cartesiaans product' het is exact de fout die ik heb gemaakt. Maar dan nog begrijp ik niet waarom dit mogelijk zou moeten zijn.

Omdat de mysql query wel correct is en uitgevoerd kan worden. Dat het voor zo'n enorme hoop zorgt in grote databases heeft mysql lak aan , de query is immers correct. Programma's denken nou eenmaal niet na , zodra invoer correct is gaat de server daarmee aan de slag , dat ie vervolgens daarop vastslaat door ondoordacht programmeerwerk is niet het probleem van mysql

Pannenkoekkie schreef op woensdag 15 maart 2006 @ 12:52:
[...]


Waar geen fout is, geen melding.

Zoals ^^ zegt dus , het is geen fout van het programma maar van de programmeur die een niet-geschikte query heeft geprogrammeerd.

[ Voor 15% gewijzigd door Raku op 15-03-2006 14:23 ]

[Fish]

gebruik anders SET ROWCOUNT ... als je aan het experimeneteren bent ....
scheelt een boel

[Spider.007]

Toch hoort mysql niet zomaar vast te slaan Heb je iets meer informatie over de hoeveelheden data, en exacte structuur? Dan verplaats ik je topic nog even

SA > DTE

[Fish]

moah ... niet vast, maar onbereikbaar

oorzaak bleek de query teveel resultaten op te vragen waardoor de MySQL demon teveel resources nam, als resultaat een server die totaal onbereikbaar is.

[teun-v]

Hij slaat ook niet echt vast, maar hij wordt inderdaad onberijkbaar en daar mee ook andere zaken zoals een ssh sessie. Laat het duidelijk zijn het probleem met de betrevende query allang is opgelost voor ik dit topic heb gestart. Wat ik vreemt vindt is dat een dergelijke query gewoon mogelijk is.

Dat verder de bovenstaande query een valide query is daar kan ik niet met mijn hoofd bij. Als iemand de reden hiervan kan noemen, dan graag.

fish schreef op woensdag 15 maart 2006 @ 22:13:
gebruik anders SET ROWCOUNT ... als je aan het experimeneteren bent ....
scheelt een boel

Zeker een goede tip, die hou ik in gedachten

[kenneth]

teun-v schreef op donderdag 16 maart 2006 @ 08:45:
Hij slaat ook niet echt vast, maar hij wordt inderdaad onberijkbaar en daar mee ook andere zaken zoals een ssh sessie. Laat het duidelijk zijn het probleem met de betrevende query allang is opgelost voor ik dit topic heb gestart. Wat ik vreemtd vindt is dat een dergelijke query gewoon mogelijk is.

Als hij syntactisch correct is, waarom zou hij niet mogelijk moeten zijn? Omdat hij semantisch incorrect is? Dat kan de parser niet ruiken

Dat verder de bovenstaande query een valide query is daar kan ik niet met mijn hoofd bij. Als iemand de reden hiervan kan noemen, dan graag.

Omdat je soms wel een Cartesisch product wil?

[bazkar]

Ik kan me voorstellen dat je JUIST dat wil in bv. iets als

select * from man,vrouw WHERE ABS(man.leeftijd - vrouw.leeftijd) < 5

geef me alle koppels waarvan de leeftijd max 5 jaar uit elkaar ligt. Ik noem maar iets dufs

[Dido]

Bovenstaand is een leuk voorbeeld. Zelf heb ik cartesische producten vooral gebruikt om snel veel testdata te genereren

[whoami]

Dit heeft niets met Development Tools te maken.
-> P

[teun-v]

bazkar schreef op vrijdag 17 maart 2006 @ 14:09:
Ik kan me voorstellen dat je JUIST dat wil in bv. iets als

select * from man,vrouw WHERE ABS(man.leeftijd - vrouw.leeftijd) < 5

geef me alle koppels waarvan de leeftijd max 5 jaar uit elkaar ligt. Ik noem maar iets dufs

Hier heb je helemaal geleik, ik zou hier nooit op gekomen zijn. Ik geloof dat ik het nut van een dergelijke query nu wel snap.

Dido schreef op vrijdag 17 maart 2006 @ 14:15:
Bovenstaand is een leuk voorbeeld. Zelf heb ik cartesische producten vooral gebruikt om snel veel testdata te genereren

Dat je dan veel data kan krijgen dat is zeker maar niet handig als dat door een klein dom foutje kom

Nou ja, iedergeval bedankt voor de reactie, het heeft me iets duidelijker gemaakt waarom dit zo is

[Woy]

Het is trouwens behoorlijk verouderd om een select te doen als

SQL:

select *
from a, b
where a.id = b.id

Je kan dan beter op de volgende manier joinen. Dat is veel duidelijker

SQL:

select *
from a
Inner join b
on a.id = b.id

Op die manier heb je je join netjes gescheiden van de rest van je where clause en kan je ook netjes per join op geven wat de conditie is om te joinen.