WordPress SQL-kyselyt: WP_Query, meta_query ja tax_query

WordPressin “taika” näyttää usein siltä, että kirjoitat muutaman rivin koodia ja saat ulos juuri oikeat artikkelit, sivut tai tuotteet. Todellisuudessa taustalla tapahtuu hyvin konkreettinen asia: WordPress muodostaa SQL-kyselyitä ja ajaa ne wpdb:n kautta MySQL/MariaDB-tietokantaan. Jos ymmärrät, miten WP_Query, meta_query ja tax_query kääntyvät SQL:ksi, alat nähdä suorituskykyongelmat ja datamallin rajat ennen kuin ne räjähtävät käsiin.

Tässä oppaassa puretaan teknisesti auki, miten WP_Query rakentuu, miten meta_query ja tax_query toimivat relaatiotasolla, millaisia JOIN-operaatioita syntyy ja miten kyselyt optimoidaan niin, että sivusto ei muutu hitaaksi “meta-tauluhelvetiksi”.

WP_Query on SQL-kone, ei sisältötaikuri

WP_Query on WordPressin keskeinen kyselyrakentaja. Kun annat sille query var -parametreja (post_type, s, meta_key, tax_query…), se:

1. normalisoi parametrit (tyypit, oletusarvot, turvallisuus)

2. rakentaa SQL:n osiin (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY, LIMIT)

3. suorittaa kyselyn wpdb:llä

4. rakentaa tuloksista WP_Post-olioita ja asettaa globaalin Loop-tilan

Tärkeä ajatus: WP_Query ei ole yksi kiinteä kysely, vaan “kyselygeneraattori”, jonka lopputulos vaihtelee valtavasti parametrien perusteella.

WP_Queryn perusparametrit ja niiden SQL-vaikutus

Yleiset parametrit ja niiden tyypillinen vaikutus SQL:ään:

• post_type: lisää WHERE-ehdon wp_posts.post_type IN (...)

• post_status: lisää WHERE-ehdon wp_posts.post_status IN (...)

• p / name / pagename: lisää WHERE-ehdon tiettyyn postin tunnisteeseen (ID tai slug)

• posts_per_page, paged: lisää LIMIT/OFFSET (tai LIMIT + “sivutuslogiikka”)

• orderby, order: lisää ORDER BY -lausekkeen

• s (haku): lisää LIKE-ehtoja yleensä post_title/post_content -kenttiin (voi olla raskas)

• date_query: lisää aikaväli- ja päivämääräsuodatuksia post_date/post_modified -kenttiin

Jo pelkkä s voi muuttaa kyselyn luonteen täysin, koska se voi estää indeksien tehokkaan käytön (LIKE ’%foo%’).

“Kaksi kyselyä yhdessä”: FOUND_ROWS ja sivutus

Kun WP_Query tekee sivutusta, se haluaa usein tietää myös kokonaisrivimäärän (max_num_pages). Perinteisesti WordPress on käyttänyt SQL_CALC_FOUND_ROWS + SELECT FOUND_ROWS() -mallia joissain tilanteissa, mutta käytännössä tärkein optimointivipu on:

• no_found_rows => true

Jos et tarvitse kokonaismäärää (esim. “näytä 6 nostoa”), tämä säästää huomattavasti.

fields, caching ja datan määrä

WP_Queryn fields voi muuttaa SELECTin:

• default: hakee post-objektit (usein wp_posts.*)

• fields => 'ids': hakee vain ID:t (kevyempi, nopeampi)

• fields => 'id=>parent' yms. tietyissä tapauksissa

Lisäksi on kaksi kriittistä “piilokustannusta”:

• postmeta-cache: update_post_meta_cache (oletuksena true)

• term-cache: update_post_term_cache (oletuksena true)

Jos haet vain ID:t ja teet oman käsittelyn, kannattaa usein säätää näitä, muuten WordPress saattaa hakea ja välimuistittaa asioita, joita et edes käytä.

pre_get_posts: kyselyn muokkaus ilman SQL-ruuvailua

Kun haluat muuttaa pääkyselyä tai tietyn näkymän logiikkaa, pre_get_posts on se “oikea” paikka. Se antaa mahdollisuuden säätää query-vareja ennen kuin SQL rakennetaan. Se on turvallisempi ja ylläpidettävämpi kuin suora SQL, ja toimii WordPressin elinkaaren kanssa nätisti.

meta_query: avain–arvo-joustavuus, JOIN-raskaus

meta_query käyttää wp_postmeta-taulua, joka on avain–arvo-malli (meta_key, meta_value). Tämä joustavuus on WordPressin supervoima ja samalla yksi sen pahimmista suorituskykyansoista.

Kun käytät meta_querya, WP_Query tekee yleensä JOINin wp_postmeta-tauluun. Ja jos sinulla on useita meta-ehtoja, WordPress joutuu usein tekemään useita JOINeja samaan tauluun eri aliaksilla, esimerkiksi:

• JOIN wp_postmeta AS mt1 ON (wp_posts.ID = mt1.post_id)

• JOIN wp_postmeta AS mt2 ON (wp_posts.ID = mt2.post_id)

Sitten WHERE-ehdot kohdistuvat mt1/mt2 -aliaksiin.

Tämä on kallista, koska:

• wp_postmeta voi olla valtava

• meta_value on usein LONGTEXT eikä indeksöidy järkevästi

• vertailut ovat usein merkkijonopohjaisia

meta_queryn tärkeimmät parametrit

meta_query koostuu ehdoista ja relationista:

• relation: AND / OR

• key: meta_key

• value: arvo (tai arvot)

• compare: =, !=, >, >=, <, <=, LIKE, IN, BETWEEN, EXISTS, NOT EXISTS…

• type: CHAR, NUMERIC, BINARY, DATE, DATETIME, DECIMAL, SIGNED, UNSIGNED…

Yksi yleisimmistä virheistä: unohdetaan type => 'NUMERIC', jolloin SQL vertaa merkkijonoina. Esimerkiksi “100” voi olla “pienempi” kuin “9” merkkijonojärjestyksessä. Tulos näyttää satunnaiselta, mutta se on vain väärää vertailua.

meta_query ja järjestäminen meta-arvolla

Kun teet orderby => 'meta_value' tai meta_value_num, WordPress joutuu yhdistämään postmeta-tauluun myös ORDER BY:n vuoksi. Tämä voi olla merkittävästi raskaampaa kuin pelkkä suodatus, koska tietokannan pitää lajitella iso joukko rivejä tekstikentän perusteella.

Jos tarvitset usein “järjestä tämän kentän mukaan” -toimintoa suurilla datamäärillä, meta_valueen nojaaminen alkaa nopeasti sattua. Tällöin tyypillinen ammattimainen ratkaisu on:

• käyttää taksonomiaa luokitteluun (jos järkevää)

• ylläpitää erillistä “denormalisoitua” taulua tai indeksoitua saraketta (oma taulu)

• esilaskettuja arvoja ja välimuistia

OR-relations ja EXISTS: miksi ne pahenevat nopeasti

relation => 'OR' meta_queryssa johtaa usein siihen, että SQL ei pysty hyödyntämään indeksejä yhtä tehokkaasti. Lisäksi EXISTS/NOT EXISTS voi aiheuttaa alikyselyitä tai laajoja skannauksia.

Perussääntö: OR + meta_query + suuri wp_postmeta on resepti hitauteen, ellei data ole pieni tai välimuisti erittäin aggressiivinen.

tax_query: taksonomiat ovat “oikea relaatiomalli” WordPressissä

tax_query käyttää wp_terms, wp_term_taxonomy ja wp_term_relationships -tauluja. Vaikka tax_query tekee useita JOINeja, se on usein skaalautuvampi kuin meta_query, koska:

• relaatiot ovat selkeästi normalisoituja

• term_taxonomy_id ja object_id ovat yleensä indeksöityjä

• suodatus perustuu numeerisiin ID:ihin, ei LONGTEXT-arvoihin

tax_queryn perusidea: yhdistetään postit termeihin liitostaulun kautta ja suodatetaan taksonomian/termin mukaan.

tax_queryn tärkeimmät parametrit

• taxonomy: esim. category, post_tag tai custom taxonomy

• field: term_id, slug, name…

• terms: yksi tai useita

• operator: IN, NOT IN, AND, EXISTS, NOT EXISTS

• include_children: erityisesti hierarkkisissa taksonomioissa

• relation: AND/OR useiden tax_query-ehtojen välillä

Yksi tärkeä huomio: operator AND tarkoittaa “postilla on kaikki nämä termit”, mikä voi kasvattaa JOIN- ja GROUP BY -tarpeita, koska tietokannan täytyy varmistaa, että kaikki ehdot täyttyvät samalle postille.

Yhdistetty meta_query + tax_query: kun SQL alkaa olla “iso kone”

Todellisessa elämässä kyselyissä yhdistetään usein:

• post_type + status

• tax_query (kategoria/tuoteryhmä)

• meta_query (hinta, varasto, ominaisuudet)

• orderby (päiväys tai meta)

Tässä kohtaa SQL voi kasvaa isoksi:

• useita JOINeja postmeta-tauluun

• useita JOINeja term-tauluihin

• mahdollinen GROUP BY wp_posts.ID deduplikointiin

• raskas ORDER BY

Yleinen optimointistrategia on vähentää muuttujia:

• Voiko osan suodatuksesta tehdä taksonomiana metan sijaan?

• Voiko hakualueen rajata (date_query, post__in, pre-filter)?

• Voiko järjestämistä muuttaa (päiväys vs meta)?

• Voiko tehdä kaksivaiheisen haun: ensin ID:t kevyesti, sitten täydet objektit?

Käytännön optimointiperiaatteet

1. Hae vain se mitä tarvitset
   Jos tarvitset listan ID:itä, käytä fields => 'ids', älä täysiä objekteja.

2. Poista turhat laskennat
   no_found_rows => true kun sivutusta ei tarvita.

3. Vältä raskaita meta_query-kokonaisuuksia
   Erityisesti OR-relations, LIKE ja laaja BETWEEN wp_postmeta:ssa.

4. Suosi taksonomioita suodatukseen
   Taksonomiakyselyt ovat usein tehokkaampia kuin meta.

5. Rajoita dataa aikaisin
   Pienempi tulosjoukko tarkoittaa nopeampaa ORDER BY:ta ja vähemmän JOIN-kuormaa.

6. Välimuisti on osa arkkitehtuuria
   Jos kysely on “kallis mutta harvoin muuttuva”, transient tai object cache on lähes aina järkevä.

7. Tunne WP_Queryn “automaattiset lisäkulut”
   Meta/term cache -päivitykset, sticky-post logiikka, suodattimet. Joskus suppress_filters tai cache-flagit ovat perusteltuja, mutta niitä pitää käyttää harkiten.

Debuggaus: miten näet SQL:n

Kun haluat ymmärtää mitä oikeasti tapahtuu, tärkeää on nähdä muodostettu SQL ja kyselyiden määrä/kesto. Käytännössä kehittäjät seuraavat:

• WP_Queryn generoitua SQL:ää (query-objektin sisällä)

• wpdb:n kyselylogia (kehityksessä)

• hitaita kyselyitä ja niiden toistuvuutta (profilointi)

Kun näet SQL:n, opit nopeasti tunnistamaan “klassiset” ongelmat:

• liikaa JOINeja wp_postmeta:an

• LIKE-suotimet isoissa tekstikentissä

• ORDER BY meta_value ilman järkevää rajausta

• GROUP BY ja HAVING -rakenteet, jotka pakottavat laajoihin laskentoihin

Milloin WP_Query ei riitä

WP_Query on erinomainen “yleiskone”, mutta jos sinulla on:

• miljoonia postmeta-rivejä

• monimutkaiset raportit

• vahvasti strukturoitu liiketoimintadata (tilaukset, inventaario, tapahtumaloki)
  …voi olla järkevämpää käyttää omaa taulua ja kohdennettuja indeksejä. WordPressin datamalli on sisällölle joustava, mutta ei aina paras “järjestelmätason transaktiodatalle”.

Lopuksi

WP_Query, meta_query ja tax_query ovat WordPressin SQL-kielenkäyttöä helpottava kerros. Kun ymmärrät, miten ne rakentavat JOINit ja WHERE-ehdot, alat suunnitella sisältömallit ja suodatukset niin, että tietokanta tekee vähemmän työtä ja välimuisti tekee enemmän. Se on WordPress-suorituskyvyn perusdiili: älä pakota wp_postmeta-taulua tekemään asioita, joihin se ei skaalaudu, ja suosi relaatiomalleja (taksonomiat, omat taulut) siellä missä järki ja liiketoiminta vaativat.