01
Dure product-/metaqueries
Filters, zoeken, custom prijzen en rapportages kunnen queries met veel JOINs bouwen waarvan de kosten sterk stijgen met de grootte van de catalogus en de metadata.
Home / WooCommerce database-optimalisatie
WooCommerce · MySQL · grote catalogi
WooCommerce database-optimalisatie voor webshops die uit hun stack zijn gegroeid.
Een WooCommerce-database begint vaak klein en voorspelbaar en verzamelt daarna orders, sessies, Action Scheduler-taken, plugintabellen, productmeta en autoloaded opties. Ik profileer de queries die echt traag zijn, repareer data-, index- en applicatiepatronen en ruim alleen op wat veilig kan.
Technische gids + implementatie · Herzien op 16 augustus 2026
01 · Wat er meestal misgaat
Het probleem zijn meestal de kosten van queries, niet te veel rijen.
Grote winkels kunnen snel draaien met miljoenen rijen als veelgebruikte queries goed ontworpen en geïndexeerd zijn. Kleine winkels kunnen slecht draaien als een plugin herhaaldelijk metadata scant, enorme opties autoloadt of ontsporend achtergrondwerk inplant.
02
Opslagpatronen van bestellingen
HPOS en de oude orderopslag hebben verschillende tabellen en queryeigenschappen. Custom code moet de juiste API's en querypatronen gebruiken in plaats van uit te gaan van posts/postmeta.
03
Opgeblazen autoload-opties
Grote geserialiseerde opties die bij elk verzoek worden geladen, verspillen geheugen en kunnen PHP- en MySQL-werk verhogen, zelfs op pagina's die die pluginstatus niet nodig hebben.
04
Achterstand in Action Scheduler
Imports, webhooks, e-mail, abonnementen en integraties kunnen grote wachtrijen veroorzaken die database- en workercapaciteit opslokken.
05
Sessies en transients
Sessies/transients die verlopen zijn en cachedata van extensies kunnen zich opstapelen. Opruimen is nuttig als het bewijs laat zien dat het de efficiëntie van queries of tabellen beïnvloedt.
06
Ontbrekende/ineffectieve indexen
Custom tabellen en pluginqueries kunnen filteren of sorteren op kolommen zonder bruikbare indexen. Een index toevoegen kan enorm helpen, maar pas nadat de exacte trage query en de afweging voor schrijfacties zijn bevestigd.
02 · Eerst diagnosticeren, dan wijzigen
Begin bij bewijs uit trage queries, niet bij folklore over wp_options.
Ik profileer echte verzoeken — product bewerken in de admin, frontendfilters, checkout, imports, rapporten — en volg de dominante SQL. Dat laat zien of de oplossing in opruimen, een index, een pluginquery, cacheontwerp of applicatiecode hoort.
Query Monitor / APM
Koppel dure SQL aan een pagina of verzoek en een plugin of callback, in plaats van tabellen te optimaliseren zonder impact voor gebruikers.
EXPLAIN / indexgebruik
Bekijk scanaantallen, de volgorde van joins en of bestaande indexen het WHERE- en ORDER BY-patroon van de echte query ondersteunen.
Autoload-payload
Meet de grootte en eigenaar van autoloaded opties; verplaats of verwijder alleen data die begrepen wordt en niet meer nodig is.
Gezondheid van de scheduler
Controleer openstaande/mislukte acties, terugkerende jobs en doorvoer, zodat achtergrondwerk niet ongemerkt alle resources opslokt.
HPOS-compatibiliteit
Controleer of custom integraties de order-API's van WooCommerce of HPOS-compatibele patronen gebruiken in plaats van directe aannames over de oude postmeta.
Groeiprofiel
Bepaal welke tabellen of datasets het snelst groeien en koppel die groei aan bedrijfsfuncties, imports, sessies of logging voordat je bewaartermijnen vastlegt.
03 · Implementation
Maak databasewerk voorspelbaar op de verzoeken die geld opleveren.
Opruimen is het verkeerde antwoord als het echte probleem een slechte query is. Ik geef de voorkeur aan wijzigingen die snel blijven terwijl orders en producten blijven groeien.
Trage workloads vastleggen
Profileer checkout, catalogusfilters/zoeken, admin en achtergrondimports/-jobs met data zoals in productie.
Applicatiequeries oplossen
Verwijder herhaalde N+1-lookups, brede metaqueries, directe SQL op de oude orderopslag en onnodige tellingen voordat je MySQL eromheen afstemt.
Gerichte indexen toevoegen
Maak of pas indexen alleen aan voor aantoonbaar waardevolle querypatronen en controleer de kosten voor schrijven en opslag.
Geladen data verminderen
Verklein te grote pluginopties of haal ze uit de autoload, en ruim veilige verlopen sessies, transients en logs op nadat het eigenaarschap is bevestigd.
Achtergrondwachtrijen beheersen
Repareer ontspoorde planningen, imports en webhook-/abonnementstaken, zodat ze niet agressief concurreren met checkout- en frontendverkeer.
Onderhoud documenteren
Leg bewaar-, opruim- en herprofileringsregels vast voor deze specifieke winkel in plaats van blind een generieke opschoner te draaien.
04 · Wat je echt krijgt
Een databaseplan gebaseerd op queries, niet op bijgeloof.
Je krijgt voor- en na-bewijs voor de verzoeken die traag waren en een onderhoudsmodel dat past bij de orders, catalogus en integraties van de winkel.
01
Bevindingen over trage queries
Dure SQL gekoppeld aan de pagina, plugin of taak die hem veroorzaakt.
02
Query-/codefixes
WooCommerce-/API-compatibele wijzigingen die herhaalde of slecht opgebouwde datatoegang wegnemen.
03
Gerichte indexen
Indexen of tabelwijzigingen onderbouwd met EXPLAIN-/querybewijs, met rollbacknotities.
04
Veilige opschoning
Alleen bekende verouderde of verlopen data wordt verwijderd, met back-up en controles op staging.
05
Tuning van scheduler/sessies
Achtergrond- en sessiedata zo beheerd dat winkelrequests op de voorgrond voorspelbaar blijven.
06
Vangrails voor groei
Advies over bewaartermijnen en monitoring voor orders, logs, feeds, webhooks en extensietabellen.
Als de checkout of wp-admin elke maand trager wordt, profileer dan de database voordat je een grotere server koopt.
Voor database-, frontend-, winkelwagen- en checkoutperformance is de bredere WooCommerce-performancedienst de juiste opdracht.
FAQ
Vragen die ik krijg voordat ik productie aanraak.
Hoe weet ik of de WooCommerce-database traag is?
Profileer echte verzoeken en bekijk databasetijd en aantallen queries. Een grote opties- of orderstabel is op zichzelf geen bewijs; het bewijs is dure SQL, hoge scanaantallen, concurrentie of herhaalde datatoegang in belangrijke workflows.
Moet ik WooCommerce-transients en -sessies verwijderen?
Verlopen of verouderde data kan worden opgeruimd, maar verwijderen is geen vervanging voor het oplossen van query- of applicatieproblemen. Begrijp waar de data bij hoort, maak eerst een back-up en verwijder geen actieve klant- of sessiestatus.
Maakt HPOS WooCommerce sneller?
HPOS geeft orders eigen tabellen en een datamodel dat op commerce is gericht. De performance hangt nog steeds af van extensies, queries, indexen en werklast, dus custom code moet HPOS-compatibel zijn.
Kan de autoload in wp_options WooCommerce vertragen?
Ja, als grote hoeveelheden pluginstatus bij elk verzoek worden geladen. Meet de totale autoload-payload en bepaal de eigenaar voordat je autoloadvlaggen wijzigt of opties verwijdert.
Kan ik gewoon een plugin voor databaseopschoning installeren?
Opschoontools kunnen revisies en transients verwijderen en tabellen optimaliseren, maar ze kunnen geen slechte custom query, ontbrekende index of ontspoorde taakwachtrij oplossen. Gebruik ze als onderhoudstools, niet voor diagnose.
Is het veilig om databaseindexen toe te voegen?
Indexen verbeteren het lezen maar kosten extra opslag en schrijfwerk. Ze moeten gebaseerd zijn op een echte trage query en getest worden met productie-achtige data en een rollbackplan, vooral bij grote tabellen.