MySQL query's sneller maken

Status
Niet open voor verdere reacties.

Robdeprop

Gebruiker
Lid geworden
12 sep 2009
Berichten
27
Hallo,

Ik ben een beginnend programmeur, en ben nu bezig een website te bouwen in PHP en MySQL. PHP kan redelijk goed, en met MySQL kan ik genoeg overweg om simpele select, update, insert enzovoort commando's te doen.

Tot zover gaat alles nog goed. Maar mijn website begint steeds meer leden te krijgen, nu meer dan 1200 (valt nog wel mee, voor elke member een row), en er beginnen steeds vaker MySQL errors te verschijnen, namelijk de "too many user connections"; de max_user_connections wordt overschreden.

Dus ik heb geïnformeerd bij mijn host, en het blijkt dat max_user_connections slechts op 15 staat... Maar ze zeiden ook, dat 1200 niet echt veel is en dat ik mijn MySQL query's en tabellen moet optimsliseren.

Ook hier ben ik weer onderzoek naar gaan doen, en een hele wereld van indexes, innerjoins, slow query logs enzovoort ging open, waar ik nu dus een beetje mijn weg in probeer te vinden.

Ik ben me een beetje gaan verdiepen in de indexen, en ik heb dus een tabel ledengegevens:

id | gebruikersnaam | wachtwoord | nog een hoop kolommen...

- Aangezien id altijd uniek is, heb ik die een PRIMARY index gegeven.

- Gebruikersnaam hoort altijd uniek te zijn, maar door een programmeerfoutje zijn er wel eens dubbelposts opgetreden, waardoor sommige er twee keer in staan, dus heb ik hem een index index gegeven.

- Verder zijn er geen indexen

Vaak wordt er gezocht met gebruikersnaam in de where clause.




Ik ga nu een voorbeeld geven:

In mijn slow MySQL query log vond ik bijvoorbeeld:

# Fri Apr 22 04:25:34 2011
# Query_time: 2.111468 Lock_time: 0.859491 Rows_sent: 1 Rows_examined: 1205
use thrdspla_members;
select wachtwoord, member_status, bantime from ledengegevens where gebruikersnaam='BlobbyM203'

Er staat: Query_time: 2.111468, dus deze query suurde meer dan 2 seconden? Maar waarom staat er Rows_examined: 1205? gebruikersnaam heeft toch een index index en daarom zou hij toch maar 1 row hoeven te doorzoeken?

Ik heb in PHPMyAdmin dus:

EXPLAIN SELECT gebruikersnaam, wachtwoord, member_status from ledengegevens where gebruikersnaam='BlobbyM203'

gedaan, en daar kwam dit uit:

id |select_type | table | type |possible_keys | key |key_len |ref | rows | Extra |

1 | SIMPLE | ledengegevens | ref | gebruikersnaam |gebruikersnaam | 17 |const |1 | Using where |

Ook is het wel vreemd dat als ik EXPLAIN weglaat PHPMyAdmin zegt dat de query maar 0.0006 seconde duurde, en in de log meer dan 2 seconden?

Ik snap het dus niet.
Waarom is de Query tijd in de log 2 seconden en in PHPMyAdmin 0.0006 seconden?
Hoezo is rows_examined 1205 terwijl hij (ook in de EXPLAIN) er maar 1 doorzoekt?
Hoe maak ik deze query sneller?

Kan iemand mij misschien een verhelderende uitleg geven?



--------------------------------------- EDIT -------------------------------------

Ik vond ook dit in mijn log:
# Sat Apr 23 04:00:07 2011
# Query_time: 5.997249 Lock_time: 2.109322 Rows_sent: 0 Rows_examined: 1
use thrdspla_members;
update ledengegevens set chatonline='1303552801',location='chat' where gebruikersnaam='JuZZo'

slechts één row bij Rows_examined, en toch een Query_time van 6 seconden? Hoezo?
 
Laatst bewerkt:
Slow query log laat zien welke specifieke queries lang duren, maar dat hoeft niet met de query te maken te hebben (en in dit geval heeft dat het ook niet)

Het lijkt er eerder op dat je server overbelast is met het een of ander en daarom die query in de wacht gezet is, en dat het daarom zo lang duurt.

Als je een provider hebt kun je die even vragen of het druk is op jouw server, het zou ook kunnen dat iemand anders bezig is. Of dat je ergens een heel inefficient stuk code hebt. Of dat je niet zozeer een probleem hebt met trage queries, maar gewoon met véel queries (veel users online en veel queries per pagina)

Probeer eens bij te houden hoeveel queries je voor een pagina nodig hebt en hoeveel pagina's er per minuut aangeroepen worden. Misschien dat je daar wat informatie uitkrijgt.

Overigens als je connections exceeded hebt moet je even heel goed kijken of je niet meer dan 1 connection per script opent en dat je geen persistent connections gebruikt.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan