Een PrestaShop-shop die vijf jaar in productie is, weegt zelden minder dan 6 GB aan database. Veel shops zitten boven de 12 GB. Het is niet de catalogus die explodeert: een catalogus van 10.000 producten met varianten, afbeeldingen en complete SEO blijft onder de gigabyte. Wat opzwelt zijn de ballasttabellen: technische tabellen die PrestaShop continu voedt en die geen enkel native proces opschoont. Na vijf jaar vertegenwoordigen ze vaak 70 tot 90% van het totale gewicht van de database.
Dit artikel brengt de schuldige tabellen in kaart, geeft de SQL-queries om de potentiële winst te meten, en legt uit hoe u een duurzaam retentiebeleid opzet zonder de shop te breken. Geen magazinechecklist: de versie die men werkelijk in productie toepast.
Waarom een PrestaShop-database geruisloos opzwelt
PrestaShop heeft geen garbage collector. Alle tabellen die events registreren, interne zoekopdrachten, verbindingen, verlaten winkelwagens, logs, verweesde metadata, groeien lineair, soms exponentieel, zonder dat enig native mechanisme een opschoning triggert.
Concreet, op een shop met 2.000 bezoekers per dag:
ps_statssearchontvangt 300 tot 800 rijen per dag (elke interne zoekopdracht, ook lege).ps_connectionsenps_connections_pageregistreren elk bezoek en elke bekeken pagina. Reken op 5.000 tot 15.000 rijen per dag.ps_guestmaakt een record aan voor elke niet-geauthenticeerde bezoeker.ps_cartbewaart alle winkelwagens, verlaten inbegrepen, voor altijd. Op sommige shops vindt men 90% lege winkelwagens uit 2018.ps_logvangt alle fouten en adminevents.
Vermenigvuldig met 365 dagen en 5 jaar: het gaat om tientallen miljoenen rijen voor een businesswaarde van nul. Het brute gewicht is niet het ergste probleem. De echte kosten zitten elders.
De verborgen kosten van de ballasttabellen
1. Queryprestaties
InnoDB laadt de indexen in het geheugen (buffer pool). Wanneer technische tabellen van meerdere GB de buffer monopoliseren, worden uw catalogus-, winkelwagen- en bestellingsqueries trager. De LCP van een productpagina kan 200 tot 400 ms extra kosten, uitsluitend door de MySQL-geheugendruk.
2. Back-ups en restores
Een mysqldump van 12 GB duurt 30 tot 60 minuten afhankelijk van de schijf. De restore kan 2 tot 4 uur duren. Overschrijdt de automatische back-up van uw hoster een tijdvenster, dan begint hij in stilte te falen. Veel shops ontdekken op de dag van een incident dat ze geen geldige back-up meer hebben.
3. Geblokkeerde migraties
Een shop van 12 GB migreren naar PHP 8.2 op een nieuwe server, of naar PrestaShop 9, vraagt de dump via rsync over te zetten, te restoren, te testen. Het gewicht vermenigvuldigt elke operatie. De “simpele” migraties worden projecten van meerdere dagen.
4. Externe modules die verzwaren
Bepaalde statistiek-, marketing- en ERP-connectormodules maken hun eigen tabellen aan en laten ze onbeperkt groeien. ps_netreviews_, ps_advancedstats_, ps_mailchimp_ zijn frequente verdachten. Een audit onthult vaak een tabel van 2 GB achtergelaten door een module die twee jaar geleden werd gedeïnstalleerd.
Audit: hoeveel weegt uw database werkelijk
Vóór elke opschoning: meten. Deze query lijst de tabellen van uw database op, gerangschikt op afnemende grootte:
SELECT
table_name AS 'Table',
ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'Size (MB)',
table_rows AS 'Rows'
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 30;U krijgt doorgaans een klassement dat eruitziet als:
ps_statssearch— 1,8 GBps_connections_page— 1,2 GBps_pagenotfound— 800 MBps_connections— 600 MBps_log— 400 MBps_cart— 350 MBps_guest— 300 MBps_cart_rule+ps_cart_cart_rule— 250 MB
Merk op dat ps_product, ps_product_lang, ps_orders zelden in de top 10 verschijnen. De echte businessdata is in de minderheid in een oude PrestaShop-database.
Kartering van de ballasttabellen en retentiebeleid
ps_statssearch — de interne zoekopdrachten
Deze tabel registreert elk woord dat in de zoekbalk wordt getypt. De historiek voorbij 90 dagen bewaren heeft geen enkel analytisch belang: de zoektrends van 2019 verhelderen niets in 2026. Aanbevolen beleid: retentie 90 dagen.
-- Audit
SELECT COUNT(*) AS total, MIN(date_add) AS oudste
FROM ps_statssearch;
-- Verwijdering voorbij 90 dagen
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_connections en ps_connections_page — de bezoekhistoriek
Gebruikt u GA4 of Matomo, dan zijn deze tabellen redundant. PrestaShop vult ze voor zijn eigen statistiekmodule die niemand raadpleegt. Beleid: retentie 30 dagen, of 0 als u een externe tool heeft.
ps_pagenotfound — de 404’s
Nuttig om de kapotte links te identificeren en 301-redirects te programmeren. Maar na behandeling dient de historiek niet meer. Beleid: retentie 60 dagen, na extractie van de terugkerende 404’s.
ps_cart — de verlaten winkelwagens
Subtiel. De recente winkelwagens dienen voor retargeting en herinneringen. Voorbij 90 dagen is een verlaten winkelwagen statistisch verloren. Beleid: 90 dagen bewaren, maar de winkelwagens gekoppeld aan bestellingen niet aanraken (join op ps_orders.id_cart).
-- Veilige verwijdering: uitsluitend de winkelwagens ZONDER gekoppelde bestelling
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON o.id_cart = c.id_cart
WHERE o.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 90 DAY);ps_guest — de niet-geauthenticeerde bezoekers
Gekoppeld aan ps_customer en ps_connections. Opschoning met voorzorg: een guest die klant is geworden, moet behouden blijven. Beleid: de guests zonder customer en zonder recente verbinding verwijderen.
ps_log — de adminlogs
Nuttig voor recente debugging, waardeloos na een maand. Beleid: retentie 30 dagen.
Verweesde metadata
Wanneer u een product verwijdert, houden bepaalde gekoppelde tabellen verweesde rijen: ps_image, ps_feature_product, ps_specific_price, ps_product_attachment. Idem voor verwijderde categorieën, fabrikanten en leveranciers. Deze rijen dienen nergens toe en vervalsen de joins.
-- Voorbeeld: verweesde ps_image
SELECT i.id_image FROM ps_image i
LEFT JOIN ps_product p ON p.id_product = i.id_product
WHERE p.id_product IS NULL;De valkuil van de DELETE in productie
Een miljoen rijen verwijderen in één enkele query op een InnoDB-tabel gelockt door uw admin en uw front, is de garantie op een crash. De binary log explodeert, de replicatie haakt af, de server kan in swap gaan.
De absolute regel: verwijderen in batches van maximaal 5.000 tot 10.000 rijen, met een pauze van 100 ms tussen elke batch.
-- Gebatchte verwijderingslus (pseudocode)
DO WHILE rows_affected > 0:
DELETE FROM ps_statssearch
WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY)
LIMIT 5000;
SLEEP 0.1;
END DO;En systematisch: dry-run vóór execute. U wilt weten hoeveel rijen zullen verdwijnen en hoeveel ruimte u recupereert voordat u klikt.
De retentie automatiseren: de correcte strategie
De opschoning één keer met de hand doen en vergeten dient nergens toe: de database zwelt weer op. De retentie moet continu en automatisch zijn:
- Dagelijkse cron die het retentiebeleid van elke tabel uitvoert.
- Beveiligingstoken zodat de cron niet van buitenaf te triggeren is.
- Uitvoeringslogs om op te volgen wat verwijderd is.
- Notificatie bij falen of anomalie (abnormaal verwijderingsvolume).
- Wekelijkse OPTIMIZE TABLE op de opgeschoonde tabellen om de schijfruimte te recupereren (anders behoudt InnoDB de toegewezen ruimte).
Onze module dfcleanup: de verpakte methode
Deze strategie handmatig implementeren vraagt twee tot drie dagen ontwikkeling en evenveel tests. Onze module dfcleanup voor PrestaShop 8 en 9 industrialiseert de hele hier beschreven methode:
- Zes gespecialiseerde cleaners: zoekopdrachten, winkelwagens, logs, statistieken, verweesde metadata, verweesde afbeeldingen. Elk met zijn eigen configureerbare retentie.
- Drie modi: Audit (alleen-lezen), Dry-run (getraceerde simulatie), Execute (gebatchte verwijdering per 5.000 rijen).
- Winst in MB berekend vóór de actie, per cleaner en in totaal.
- Crontaak beveiligd met token, klaar voor gebruik.
- Gedetailleerde logs en compatibiliteit met PrestaShop 8 en 9.
Voor 19 € vermijdt u de handmatige DELETE-queries en installeert u een duurzaam retentiebeleid. Vergeleken met de ontwikkeltijd en de kosten van een DBA-incident is het een van de modules met de beste ROI van de catalogus.
FAQ
Moet men na elke DELETE een OPTIMIZE TABLE doen?
Nee, niet na elke DELETE: dat is duur in I/O en lockt de tabel. Eén keer per week of per maand, in de daluren, op de tabellen die een massale opschoning hebben ondergaan. OPTIMIZE TABLE recupereert de schijfruimte die InnoDB na verwijdering niet natuurlijk vrijgeeft.
Kan de opschoning de SEO of de statistieken beïnvloeden?
Geen enkele SEO-impact: de opgeschoonde tabellen zijn technisch (interne zoekopdrachten, verbindingen, logs), niet de catalogus of de URL’s. Aan statistiekkant: gebruikt u GA4 of Matomo, dan is uw data bij hen opgeslagen en is de PrestaShop-database redundant. Gebruikt u de native PS-statistieken, configureer dan een langere retentie (180 dagen bijvoorbeeld).
Welke retentie voor de verlaten winkelwagens?
90 dagen volstaan ruimschoots. De winkelwagenherinneringstools (mail, retargeting) triggeren binnen 24 tot 72 uur. Voorbij 90 dagen is de herstelwaarschijnlijkheid statistisch nul. En u verwijdert nooit een winkelwagen die tot een bestelling heeft geleid: de join op ps_orders.id_cart beschermt die data.
Hoeveel winst concreet te verwachten?
Op een shop van 5 jaar met 2.000 bezoekers per dag meten wij gemiddeld 60 tot 80% reductie van de database bij de eerste doorgang. Een shop van 12 GB zakt terug naar 3 of 4 GB. De volgende doorgangen stabiliseren de database op een niveau dicht bij het “echte businessgewicht”.
Is de module compatibel met multi-shop?
Ja. De cleaners respecteren de multi-shop scope waar relevant (winkelwagens, zoekopdrachten per shop). De globale tabellen (logs, verbindingen) worden globaal opgeschoond.
Om verder te gaan
De databaseschuld is een van de drie belangrijkste bronnen van langetermijn-prestatiedegradatie van een PrestaShop-shop, samen met de verouderde externe modules en de slecht geoptimaliseerde afbeeldingen. Zie ook onze Core Web Vitals checklist 2026 voor de rest van het plaatje, en de gids PrestaShop 9 vs 8 als u een migratie voorbereidt: de database verlichten vóór de migratie kan de omschakeltijd door 5 delen.
Om in actie te komen: onze modulesselectie voor onderhoud, back-up en betrouwbaarheid en die om uw shop te versnellen.
