Waarom selecteer je uit 2 tabellen? Zou je niet beter met een join kunenn werken? Dus je select de song en doet inner join aritiest = artiest.id = song.artiestid

Volgens mij hoef mysql dan ook niet 2 tablellen te doorlopen. Ik heb geen idee of dit zo werkt want mijn mysql kennis is niet zo heel sterk, maar ikzelf gebruik eigenlijk nooit 2 tabellen bij from.

Code:

SELECT a.name AS artist, 
s.id AS id, 
s.title AS title, 
s.views AS views,
s.movieChecked AS checked
FROM song AS s
INNER JOIN artist AS a
ON s.artistid = a.id
ORDER BY a.name ASC, s.title ASC
LIMIT 0 , 50

@ Peter R: Ikzelf ben ook zeer tevreden over Versio. Ik zal hun eens een mailtje sturen.

@ Maarten vL: Ja, MySQL blijft gewoon reageren, hetzij enorm traag. Als ik de processlist bekijk staat er bij de Query als state: *** DEAD *** het grootste gedeelte van de tijd.

@ Raymond Karsten: Een join of de methode die ik gebruik maakt niets uit, helaas. Bij uw methode hetzelfde geval, de ORDER BY maakt het sloom.

Ik denk dat ik inderdaad maar eens moet gaan kijken naar caching.
Aanvullend bericht:
Ik denk dat ik het als volgt ga oplossen:

Ik maak een cache tabel aan met de velden songid, artist en title met een INDEX op artist en title.

Als er iets gewijzigd wordt in de originele tabellen zorg ik ervoor dat dmv een cronjob de cache tabel wordt geupdate 's nachts.

In de testen die ik heb gedraait is dit een hele snelle oplossing. Door die INDEX op artist en title gaat de ORDER BY via die INDEX en is er geen filesort nodig.

Dit lijkt mij de beste en minst "zware" oplossing. Iemand suggesties of opmerkingen?

Origineel gepost door Wouter Carabain

@ Peter R: Ikzelf ben ook zeer tevreden over Versio. Ik zal hun eens een mailtje sturen.

@ Maarten vL: Ja, MySQL blijft gewoon reageren, hetzij enorm traag. Als ik de processlist bekijk staat er bij de Query als state: *** DEAD *** het grootste gedeelte van de tijd.

@ Raymond Karsten: Een join of de methode die ik gebruik maakt niets uit, helaas. Bij uw methode hetzelfde geval, de ORDER BY maakt het sloom.

Ik denk dat ik inderdaad maar eens moet gaan kijken naar caching.
Aanvullend bericht:
Ik denk dat ik het als volgt ga oplossen:

Ik maak een cache tabel aan met de velden songid, artist en title met een INDEX op artist en title.

Als er iets gewijzigd wordt in de originele tabellen zorg ik ervoor dat dmv een cronjob de cache tabel wordt geupdate 's nachts.

In de testen die ik heb gedraait is dit een hele snelle oplossing. Door die INDEX op artist en title gaat de ORDER BY via die INDEX en is er geen filesort nodig.

Dit lijkt mij de beste en minst "zware" oplossing. Iemand suggesties of opmerkingen?

Wat je kan doen is dat bij een wijziging de cache gelijk geupdate wordt waardoor alles direct bijgewerkt worden. Daarnaast zou ik de cache opslaan in een tekst bestand aangezien de cache vaak hierdoor nog sneller is, maar dit is per situatie anders.

Origineel gepost door D. Koop

Volgens mij is het probleem dat er zoveel regels zijn.

2 minuten voor deze query? Best ziek volgens mij ;)
Ik heb beperkte ervaring met (grote) databases, hier even een voorbeeld:

Voorbeeld:
2 tabellen
1 - 183.000 regels
2 - 68.000 "
3 - 2.000 "

Tabel 2 wordt doorzocht op een match met een of meerdere ingevoerde keywords. Wanneer er een positief resultaat is, wordt de koppeltabel 1 erbij gehaald en de link gelegd naar tabel 3.
Daarnaast wordt er (tegelijkertijd) een ranking uitgevoerd met behulp van tabel 1, 2 en 3 (Correcte uitleg onder voorbehoud, is al een oud projectje :P).
Zelfs wanneer er veel resultaten zijn (en er dus meerdere koppelingen moeten worden gemaakt m.b.v. tabel 1 met tabel 3), duurt het nooit langer dan 5-6 seconden. En dan was dit nog een studie-project waar nooit tijd is gestoken in optimalisatie van de queries..

Als het echt zo is dat alle ruimte op je server verkocht is, en je dus met een zeer groot aantal gebruikers op 1 server zit (en er dus een flinke serverload komt), dan kan dat echt wel een oorzaak zijn dat je queries zo langzaam zijn..!

Origineel gepost door Bram Wenting

2 minuten voor deze query? Best ziek volgens mij ;)
Ik heb beperkte ervaring met (grote) databases, hier even een voorbeeld:

Voorbeeld:
2 tabellen
1 - 183.000 regels
2 - 68.000 "
3 - 2.000 "

Tabel 2 wordt doorzocht op een match met een of meerdere ingevoerde keywords. Wanneer er een positief resultaat is, wordt de koppeltabel 1 erbij gehaald en de link gelegd naar tabel 3.
Daarnaast wordt er (tegelijkertijd) een ranking uitgevoerd met behulp van tabel 1, 2 en 3 (Correcte uitleg onder voorbehoud, is al een oud projectje :P).
Zelfs wanneer er veel resultaten zijn (en er dus meerdere koppelingen moeten worden gemaakt m.b.v. tabel 1 met tabel 3), duurt het nooit langer dan 5-6 seconden. En dan was dit nog een studie-project waar nooit tijd is gestoken in optimalisatie van de queries..

Als het echt zo is dat alle ruimte op je server verkocht is, en je dus met een zeer groot aantal gebruikers op 1 server zit (en er dus een flinke serverload komt), dan kan dat echt wel een oorzaak zijn dat je queries zo langzaam zijn..!

Dat zeg ik dus, trage servers trage query en het hoeft heel waarschijnlijk niet iedere keer opnieuw gedaan te worden omdat het meestal toch allemaal hetzelfde is. Caching versneld echt een hoop;-)

Sowiezo zou ik gaan kijken naar caching! Ik weet niet op welke plek deze query staat maar cachen van bepaalde onderdelen in je website is echt een goed idee.

Soms is het ook handig om eerst een result set te halen van de ene tabel en daarna de gegevens te laden van de andere tabel... soms werken twee queries namelijk veel sneller dan 1!

De data is inderdaad in de meeste gevallen hetzelfde. Ik ben al bijna klaar met het implementeren van de cache, en het werkt echt perfect!

Bedankt voor de tips!