Performance

MySQL table cache

Dit is voorlopig het laatste deel over MySQL tuning. In de eerdere delen zagen we al dat een juiste instelling van de query_cache en key_buffer variabelen voor een betere performance van MySQL kunnen zorgen. De table_cache variabele verhoogt helaas niet de performance. Toch is een correcte instelling wel essentieel. Een foute (te lage) instelling beinvloedt de performance van MySQL in negatieve zin. Eerst maar eens onderzoeken wat de standaard instelling van MySQL is voor de table_cache.

MySQL Key buffers

In een andere howto hebben we gekeken hoe we ervoor kunnen zorgen dat MySQL queries kon oplsaan in zijn cache waardoor er een performance winst geboekt kan worden wanneer dezelfde query nogmaals wordt uitgevoerd. Voor de keys of indexen bestaat er eenzelfde mechanisme. Ik zal bij de behandeling ervan niet ingaan op de uitbreiding van dit principe in versie 4.1 en hoger.

indexing matters

Dit is meer dan alleen een geheugensteuntje aan mezelf. Het wordt maar al te eenvoudig vergeten terwijl het zo veel verschil kan uitmaken. De wetenschap dat goed indexeren op een grote database bijna zwarte magie is, wil nog niet voorschrijven dat we bij gebrek aan toverspreuken dit helemaal over kunnen slaan.
Zolang je slechts een tabel raadpleegt waar zo'n 7000 rows in zitten zal je niet veel merken van de afwezigheid van indexering. Maar zodra je een join uitvoert gaan de wetten van de grote getallen werken. Ik maakte de fout om de indexering 'later'[1] wel even te doen. De verschillen in tijd spreken voor zichzelf denk ik. De query was vrij simpel

select * from a join b on a.f = b.f where a.g = '100'

Zonder index: 54 seconden
Met index: 0.13 seconden
Uit de cache: 0.05 seconden
En dat door simpelweg in beide tabellen een index te benoemn op veld 'f'. Doe dit als je de database aanmaakt, doe je zwarte magie dan achteraf door gecombineerde sleutels te verzinnen.


Syndicate content
thank you for watching  Creative Commons License