Zeer trage database verzoeken/queries
Ik sta voor een raadsel. Al een hele poos is een stukje programmatuur welke gebruik maakt van een database zeer traag. Echt heel traag.
Wat is de situatie:
Er is een db tabelx met 9000 verschillende records en een db tabely met 7000 verschillende records.
Voor het opvragen van de laatste 20 records (met een status gelijk aan !='1') gebruik ik de volgende query:
Code (php)
1
SELECT * FROM tabely AS ty INNER JOIN tabelx AS tx ON (ty.status!='1' AND tx.nrid=ty.nrid) ORDER BY ty.nrid DESC LIMIT 0,20
Ik ben niet een specialist in queries, maar ik dacht dat ik zelf de query redelijk goed had opgebouwd. Maar het opvragen van de data duurt echt heel erg lang... In de db tabellen staan zo'n 15 velden.
Ik ben zeer benieuwd naar een mogelijke oplossing.
Bij jou zie ik in de join 2 velden die, op het eerste gezicht, totaal niets met elkaar te maken hebben. Denk dat het dan erg lastig wordt om een join (= doornede) van de 2 tabellen te bepalen.
Gewijzigd op 11/04/2014 17:49:55 door Pipo Clown
In de INNER JOIN staat het volgende: (ty.status!='1' AND tx.nrid=ty.nrid)
De tx.nrid=ty.nrid checkt of de nrid uit tx en ty overeenkomen.
En de ty.status!='1' zegt lijkt me heel duidelijk dat alle resultaten die NIET 1 zijn moeten worden opgehaald.
Wat gaat er volgens jouw niet goed dan? Hoe zou jij mijn query bouwen dan?
Toon Records 0 - 19 (20 totaal, Query duurde 43.1534 sec)
Ik krijg na het uitvoeren van die query dus wel mijn gewenste resultaat, maar zo ontzettend traag zoals je ziet.
Nadat ik EXPLAIN voor m'n query heb gezet krijg ik het volgende resultaat:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE ty ALL NULL NULL NULL NULL 6661 Using temporary; Using filesort
1 SIMPLE tx ALL NULL NULL NULL NULL 8918 Using where
NULL bij de keys betekent dat er geen indexen gebruikt worden.
Ergo, er worden eerst 6661 x 8918 rijen geselecteerd, en daarvan de eerste 20 getoond.
Of beter gezegd, hoe zet ik dan de index-en in?
UPDATE:
via PHPmyadmin heb ik een index toegekend aan de beide tabellen. Met het EXPLAIN hulpje krijg ik nu het volgende resultaat:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE od ALL NULL NULL NULL NULL 6661 Using where; Using temporary; Using filesort
1 SIMPLE ww ref nrid nrid 50 func 1 Using where
Toevoeging op 11/04/2014 20:13:14:
Ger, op basis van je reactie ben ik nog even flink wezen rond zoeken op het internet om te begrijpen wat er precies met de index-en moet gebeuren. Maar schaam schaam... nooit aan gedacht. In mijn nieuwe database waren er naast de primaire keys nog geen index-en gedefinieerd.
Het werkt nu weer snel, zoals het hoort.
Thanks iedereen voor de reacties!
Gewijzigd op 11/04/2014 19:29:41 door Johnny Cash