WordPress ja MySQL slow query log analyysi

Kun WordPress-sivusto hidastuu ilman selvää syytä, katse kääntyy usein PHP-koodiin, lisäosiin tai palvelinresursseihin. Todellinen syyllinen löytyy kuitenkin yllättävän usein tietokannasta. MySQL:n slow query log on yksi tehokkaimmista mutta alikäytetyimmistä työkaluista WordPressin suorituskykyongelmien diagnosointiin.

Slow query log ei kerro mielipiteitä. Se kertoo faktat: mitkä kyselyt ovat hitaita, kuinka usein ne ajetaan ja kuinka paljon ne kuormittavat järjestelmää. Kun WordPress kohtaa skaalausongelmia, tämä loki paljastaa lähes aina todelliset pullonkaulat.

Mikä slow query log on

MySQL:n slow query log tallentaa SQL-kyselyt, jotka ylittävät määritellyn aikarajan. Tyypillisesti lokiin päätyvät kyselyt, jotka kestävät esimerkiksi yli 1 sekunnin, mutta raja voidaan asettaa huomattavasti matalammaksi (0.1–0.5 s) WordPress-ympäristöissä.

Lokimerkintä sisältää yleensä:
– ajetun SQL-kyselyn
– suoritukseen kuluneen ajan
– lukittujen rivien määrän
– luettujen rivien määrän
– aikaleiman

Tämä data on raakaa, mutta juuri siksi arvokasta.

Miksi slow query log on erityisen tärkeä WordPressissä

WordPress käyttää dynaamista kyselymallia:
– paljon pieniä SELECT-kyselyitä
– meta-tauluihin perustuva rakenne
– runsaasti JOIN-operaatioita
– lisäosien generoimia custom queryjä

Yksittäinen hidas kysely ei välttämättä tunnu pahalta. Ongelma syntyy, kun:
– sama hidas kysely ajetaan jokaisella sivulatauksella
– kysely ajetaan silmukassa
– kysely osuu kuormitettuun meta-tauluun

Slow query log paljastaa nämä kuviot armottomasti.

Tyypillisimmät WordPressistä löytyvät hitaat kyselyt

wp_postmeta ja wp_usermeta

Meta-taulut ovat WordPressin suurin suorituskykivelka. Slow query logissa näkyy usein:
– WHERE meta_key = ’…’ AND meta_value = ’…’
– useita JOINeja wp_posts-tauluun
– täydellisiä tauluskannauksia

Erityisesti serialisoidun datan haku on myrkkyä suorituskyvylle.

WP_Query ilman rajoituksia

Kyselyt, joissa:
– ei ole LIMITiä
– haetaan kaikki postit
– yhdistetään useita taxonomy- ja meta-queryjä

nousevat esiin slow query logissa nopeasti.

Autoloaded options

Vaikka ne eivät näy suorina hitaina SELECT-kyselyinä, suuri autoload = yes -datamäärä aiheuttaa:
– pitkiä kyselyitä wp_options-tauluun
– korkeaa memory-käyttöä
– hitaita admin- ja frontend-pyyntöjä

Analysointi käytännössä

Pelkkä loki ei vielä auta. Olennaista on analyysi.

Hyviä kysymyksiä:
– Toistuuko sama kysely satoja kertoja?
– Tuleeko kysely coresta, teemasta vai lisäosasta?
– Onko kyse SELECT-, UPDATE- vai DELETE-kyselystä?
– Onko ongelma indeksoinnissa vai logiikassa?

Tyypillinen löydös on kysely, joka kestää 300 ms, mutta ajetaan 20 kertaa per sivulataus. Yhtäkkiä 6 sekuntia katoaa mystisesti.

Indeksit: ensimmäinen mutta ei ainoa ratkaisu

Slow query log paljastaa usein puuttuvat tai väärät indeksit. Meta-tauluissa tämä on klassista:
– meta_key ilman indeksiä
– yhdistelmäehdot ilman compoonline-indeksiä

Indeksien lisääminen auttaa, mutta:
– liialliset indeksit hidastavat kirjoituksia
– väärä indeksi ei auta ollenkaan
– serialisoitu data ei hyödynnä indeksejä

Indeksi ei korjaa huonoa kyselyä, se vain pehmentää sitä.

Lisäosat ja näkymätön kuorma

Monet lisäosat:
– ajavat kyselyitä jokaisella sivulatauksella
– eivät välimuistita tuloksia
– eivät skaalaudu käyttäjämäärän kasvaessa

Slow query log on usein ainoa tapa osoittaa, että ongelma ei ole palvelimessa vaan lisäosan arkkitehtuurissa.

Object cache ja slow query log

Object cache (Redis, Memcached) voi piilottaa ongelman, mutta ei poistaa sitä. Slow query log näyttää:
– cache miss -tilanteet
– kyselyt, jotka eivät koskaan mene cacheen
– virheellisesti rakennetut cache-avaimet

Tämä tekee lokista arvokkaan myös välimuistia käytettäessä.

Tuotanto vs kehitys

Kehitysympäristössä slow query log on usein tyhjä. Tuotannossa se täyttyy nopeasti. Tämä ero syntyy:
– oikeasta datamäärästä
– rinnakkaisista pyynnöistä
– realistisesta käyttäjäkäytöksestä

Siksi analyysi pitää tehdä tuotannon datalla tai sen realistisella kopiolla.

Ylläpidon näkökulma

Slow query log ei ole kertaluonteinen työkalu. Se on jatkuvan ylläpidon väline:
– seurataan regressioita
– havaitaan uudet pullonkaulat
– validoidaan optimointien vaikutus

Ilman sitä WordPress-optimointi on arvailua.

Yhteenveto

MySQL slow query log on yksi tehokkaimmista työkaluista WordPressin suorituskyvyn ymmärtämiseen. Se paljastaa:
– hitaat ja toistuvat kyselyt
– meta-taulujen ongelmat
– lisäosien piilokuorman
– indeksoinnin puutteet

WordPress ei kaadu hitaista kyselyistä. Se vain muuttuu raskaaksi, tahmeaksi ja arvaamattomaksi. Slow query log tekee tästä näkymättömästä ongelmasta näkyvän – ja juuri siksi se on korvaamaton large-scale WordPress-ympäristöissä.