WordPressin tietokanta paisuu harvoin yhdessä yössä. Se kasvaa hitaasti: pluginien jäämät, transientit, logit, revisionit ja “unohtuneet” custom-taulut kertyvät vuosien aikana. Lopputulos on database bloat, joka näkyy hitaana WP_Queryna, kasvaneena backup-kokona ja heikentyneenä suorituskykynä.
Nämä ovat usein pahimpia “piilokasvattajia”....
SHOW TABLES; Tämä paljastaa:...
DELETE FROM wp_posts WHERE post_type = 'revision'; Parempi:...
Database bloat aiheuttaa:...
WordPress database bloat ei ole yksittäinen ongelma, vaan ajan myötä kasaantuva ilmiö, joka syntyy:...
WordPress database bloat ei ole yksittäinen ongelma, vaan ajan myötä kasaantuva ilmiö, joka syntyy:...
WordPress database bloat ei ole yksittäinen ongelma, vaan ajan myötä kasaantuva ilmiö, joka syntyy:...
Erityisen hankalia ovat piilevät taulut ja “orvot” rakenteet, joita WordPress ei itse hallitse.
Mikä aiheuttaa database bloatin WordPressissä
1. wp_posts-taulun kasvu
- revisionit (post revisions)
- autosave-versiot
- draftit ja roskaversiot
- WooCommerce orderit (custom post type)
2. wp_postmeta räjähtäminen
- jokainen plugin lisää meta-kenttiä
- WooCommerce tuotteet = satoja meta-rivejä per tuote
- huonosti suunnitellut custom fields
3. wp_options ja autoload
- liian suuri autoload-data
- pluginien “jääneet” asetukset
- transientit jotka eivät koskaan puhdistu
4. custom plugin -taulut
- analytics pluginit
- page builderit
- cache- ja logijärjestelmät
- WooCommerce lisäosat
Nämä ovat usein pahimpia “piilokasvattajia”.
Piilevien taulujen tunnistaminen
1. Kaikki taulut listattuna
SHOW TABLES;
Tämä paljastaa:
- wp_* taulut
- sekä kaikki “ylimääräiset” plugin-taulut
2. Etsi WordPressin ulkopuoliset taulut
Tyypillinen tarkistus:
- wp_ prefix
- muut prefixit = usein pluginien jäänteitä
SQL:
SELECT table_name
FROM information_schema.tables
WHERE table_schema = DATABASE();
3. Taulujen koon analyysi
SELECT
table_name,
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC;
Tämä näyttää:
- mitkä taulut oikeasti syövät tilaa
- usein yllätyksiä kuten postmeta tai plugin-logit
4. “Orpojen” plugin-taulujen tunnistus
Etsi tauluja, joita ei enää käytetä:
- plugin poistettu, mutta taulu jäänyt
- nimi viittaa vanhaan pluginin (esim. wp_yoast_, wp_wf_, wp_rocket_)
5. Autoload-bloatin tarkistus
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;
Database bloatin puhdistusstrategiat
1. Revisionien siivous
Poista vanhat revisiot:
DELETE FROM wp_posts
WHERE post_type = 'revision';
Parempi:
- rajoita revisioiden määrää jatkossa:
define('WP_POST_REVISIONS', 5);
2. Transienttien puhdistus
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%';
Huom:
- osa transientteja kuuluu object cacheen
- Redis-hoidetussa ympäristössä vähemmän kriittistä
3. Orpojen postmeta-rivien siivous
Tyypillinen ongelma:
- post poistettu → meta jää
DELETE pm
FROM wp_postmeta pm
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
WHERE wp.ID IS NULL;
4. wp_options siivous (varovasti)
Etsi käyttämättömät optionit:
- poistettujen pluginien avaimet
- debug-jäämät
- cache leftovers
Mutta:
→ tämä vaatii aina manuaalisen tarkistuksen ennen poistoa
5. Orvot custom taulut
Kun plugin poistetaan:
- taulut jäävät usein jäljelle
- ne voivat olla gigatavuluokkaa
Esimerkkejä:
- analytics_event_log
- wc_session_data
- pluginname_cache
Ratkaisu:
- tarkista kuuluuko taulu aktiiviseen pluginin
- jos ei → arkistoi tai poista
6. Index optimointi
Isoissa WordPress-asennuksissa ongelma ei ole vain data vaan:
- puuttuvat indeksit
- väärät indeksit
ANALYZE TABLE wp_postmeta;
Suorituskykyvaikutukset
Database bloat aiheuttaa:
1. Hitaat WP_Queryt
- postmeta-skannaus kasvaa
- SQL execution time nousee
2. Backup hidastuu
- dumpit voivat kasvaa gigatavuihin
3. Restore riskit
- palautus kestää kauan
- timeout-ongelmat
4. RAM & CPU piikit
- erityisesti JOIN-heavy queryissä
Piilevät “tappajat” käytännössä
1. WooCommerce
- orders = valtava posts + postmeta yhdistelmä
- sessions ja transients
2. Page builderit
- Elementor / WPBakery
- massiiviset JSON-meta-rakenteet
3. Analytics pluginit
- event-logit ilman rotaatiota
4. Backup pluginit
- jättävät staging-tauluja
Ennaltaehkäisy
1. Rajoita revisiot
- WP_POST_REVISIONS
2. Käytä Redis object cachea
- vähentää wp_options kuormaa
3. Cron cleanup
- WP-Cron tai system cron siivoamaan:
- transients
- revisions
- orphaned meta
4. Seuraa kasvua
- kuukausittainen taulujen koon auditointi
Yhteenveto
WordPress database bloat ei ole yksittäinen ongelma, vaan ajan myötä kasaantuva ilmiö, joka syntyy:
- postmeta-räjähdyksestä
- pluginien jättämistä tauluista
- transient- ja options-kasvusta
- sekä huonosti suunnitelluista custom-rakenteista
Todellinen optimointi ei ole pelkkä siivous, vaan:
- rakenteiden ymmärtäminen
- turhan datan estäminen etukäteen
- ja säännöllinen auditointi
Kun tietokanta pidetään “kevyenä”, WordPress pysyy nopeana vaikka sisältö kasvaa vuosia.