# Perché il tuo database PrestaShop pesa 8 GB nel 2026: audit, pulizia e strategia di retention delle tabelle zavorra > Un negozio PrestaShop attivo da 5 anni pesa 6-12 GB in database, di cui l'80% sono tabelle zavorra mai pulite. Audit, mappatura, politica di retention — e automazione. Senza rompere il negozio. - Pagina: - Lingua: it - Pubblicato il: 2026-06-14 - Aggiornato il: 2026-10-10 - Altre lingue: [fr](https://www.datafirefly.com/2026/06/14/base-prestashop-tables-ballast-nettoyage-retention-2026/index.md), [en](https://www.datafirefly.com/en/2026/06/14/prestashop-database-ballast-tables-cleanup-retention-2026/index.md), [es](https://www.datafirefly.com/es/2026/06/14/base-prestashop-tablas-ballast-limpieza-retencion-2026/index.md), [de](https://www.datafirefly.com/de/2026/06/14/prestashop-datenbank-ballast-tabellen-bereinigung-retention-2026/index.md), [pl](https://www.datafirefly.com/pl/2026/06/14/baza-prestashop-tabele-balastowe-czyszczenie-retencja-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/06/14/prestashop-database-ballasttabellen-opschonen-retentie-2026/index.md), [pt](https://www.datafirefly.com/pt/2026/06/14/base-prestashop-tabelas-lastro-limpeza-retencao-2026/index.md) - Indice: Un negozio PrestaShop in produzione da cinque anni pesa raramente meno di 6 GB di database. Molti superano i 12 GB. Non è il catalogo che esplode — un catalogo di 10.000 prodotti con combinazioni, immagini e SEO completa sta sotto il gigabyte. Ciò che gonfia il database sono le **tabelle zavorra**: tabelle tecniche che PrestaShop alimenta in continuazione e che nessun processo nativo pulisce. Dopo cinque anni rappresentano spesso il 70-90% del peso totale del database. Questo articolo mappa le tabelle colpevoli, fornisce le query SQL per misurare il guadagno potenziale e spiega come impostare una politica di retention duratura senza rompere il negozio. Non una checklist da rivista — la versione che applichiamo realmente in produzione. ## Perché un database PrestaShop si gonfia silenziosamente PrestaShop non ha un garbage collector. Tutte le tabelle che registrano eventi — ricerche interne, connessioni, carrelli abbandonati, log, metadati orfani — crescono linearmente, a volte esponenzialmente, senza che nessun meccanismo nativo inneschi una pulizia. Concretamente, su un negozio con 2.000 visitatori al giorno: - `ps_statssearch` riceve 300-800 righe al giorno (ogni ricerca interna, anche vuota). - `ps_connections` e `ps_connections_page` registrano ogni visita e ogni pagina vista. Calcolate 5.000-15.000 righe al giorno. - `ps_guest` crea un record per ogni visitatore non autenticato. - `ps_cart` conserva tutti i carrelli — compresi quelli abbandonati — per sempre. Su alcuni negozi troviamo il 90% di carrelli vuoti datati 2018. - `ps_log` cattura tutti gli errori e gli eventi admin. Moltiplicate per 365 giorni e 5 anni: parliamo di decine di milioni di righe per un valore di business pari a zero. Il peso bruto non è il problema peggiore. Il vero costo è altrove. ## Il costo nascosto delle tabelle zavorra ### 1. Performance delle query InnoDB carica gli indici in memoria (buffer pool). Quando tabelle tecniche da diversi GB monopolizzano il buffer, le tue query di catalogo, carrello e ordine diventano più lente. L'LCP di una scheda prodotto può richiedere 200-400 ms supplementari solo a causa della pressione memoria su MySQL. ### 2. Backup e ripristino Un dump `mysqldump` da 12 GB impiega 30-60 minuti secondo il disco. Il ripristino può richiedere 2-4 ore. Se il backup automatico del tuo hosting supera la finestra oraria, comincia a fallire in silenzio. Molti negozi scoprono di non avere più un backup valido il giorno di un incidente. ### 3. Migrazioni bloccate Migrare un negozio da 12 GB in PHP 8.2 verso un nuovo server, o verso PrestaShop 9, richiede di trasferire il dump via `rsync`, ripristinare, testare. Il peso moltiplica ogni operazione. Le migrazioni "semplici" diventano progetti di diversi giorni. ### 4. Moduli di terze parti che appesantiscono Alcuni moduli di statistiche, marketing o connettori ERP creano tabelle proprie e le lasciano crescere indefinitamente. `ps_netreviews_`, `ps_advancedstats_`, `ps_mailchimp_` sono sospetti frequenti. Un audit rivela spesso una tabella da 2 GB lasciata da un modulo disinstallato due anni fa. ## Audit: quanto pesa davvero il tuo database Prima di qualsiasi pulizia, si misura. Questa query elenca le tabelle del tuo database ordinate per dimensione decrescente: ``` 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; ``` In genere ottieni una classifica simile a: 1. `ps_statssearch` — 1,8 GB 2. `ps_connections_page` — 1,2 GB 3. `ps_pagenotfound` — 800 MB 4. `ps_connections` — 600 MB 5. `ps_log` — 400 MB 6. `ps_cart` — 350 MB 7. `ps_guest` — 300 MB 8. `ps_cart_rule` + `ps_cart_cart_rule` — 250 MB Nota che `ps_product`, `ps_product_lang`, `ps_orders` compaiono raramente nella top 10. I dati di business reali sono minoritari in un database PrestaShop datato. ## Mappatura delle tabelle zavorra e politica di retention ### ps_statssearch — le ricerche interne Questa tabella registra ogni parola digitata nella barra di ricerca. Conservare lo storico oltre i 90 giorni non ha alcun interesse analitico: le tendenze di ricerca del 2019 non illuminano niente nel 2026. **Politica consigliata: retention 90 giorni.** ``` -- Audit SELECT COUNT(*) AS total, MIN(date_add) AS plus_ancien FROM ps_statssearch; -- Eliminazione oltre i 90 giorni DELETE FROM ps_statssearch WHERE date_add < DATE_SUB(NOW(), INTERVAL 90 DAY); ``` ### ps_connections e ps_connections_page — lo storico delle visite Se usi GA4 o Matomo, queste tabelle sono ridondanti. PrestaShop le riempie per il suo modulo di statistiche interno che nessuno consulta. **Politica: retention 30 giorni, o 0 se hai uno strumento esterno.** ### ps_pagenotfound — i 404 Utile per identificare i link rotti e programmare redirect 301. Ma dopo il trattamento, lo storico non serve più. **Politica: retention 60 giorni, dopo aver estratto i 404 ricorrenti.** ### ps_cart — i carrelli abbandonati Sottile. I carrelli recenti servono al retargeting e ai recuperi. Oltre i 90 giorni, un carrello abbandonato è statisticamente perso. **Politica: conservare 90 giorni, ma non toccare mai i carrelli legati a ordini (tabella join ps_orders.id_cart).** ``` -- Eliminazione sicura: solo i carrelli SENZA ordine associato 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 — i visitatori non autenticati Legata a `ps_customer` e `ps_connections`. Pulizia con cautela: un guest convertito in customer deve essere preservato. **Politica: eliminare i guest senza customer e senza connessione recente.** ### ps_log — i log admin Utili per il debug recente, senza valore oltre un mese. **Politica: retention 30 giorni.** ### Metadati orfani Quando elimini un prodotto, alcune tabelle correlate conservano righe orfane: `ps_image`, `ps_feature_product`, `ps_specific_price`, `ps_product_attachment`. Idem per le categorie, i produttori, i fornitori eliminati. Queste righe non servono a niente e falsano le join. ``` -- Esempio: ps_image orfane 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; ``` ## La trappola del DELETE in produzione Eliminare un milione di righe in un'unica query su una tabella InnoDB bloccata dal tuo admin e dal tuo front, significa garantirsi un crash. Il binary log esplode, la replica si stacca, il server può andare in swap. La regola assoluta: **eliminare a lotti di 5.000-10.000 righe massimo, con una pausa di 100 ms tra ogni lotto**. ``` -- Ciclo di eliminazione a lotti (pseudo-codice) 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; ``` E sistematicamente: **dry-run prima di execute**. Vuoi sapere quante righe spariranno e quanto spazio recupererai prima di cliccare. ## Automatizzare la retention: la strategia corretta Fare la pulizia manualmente una volta e dimenticarsene non serve a nulla — il database tornerà a gonfiarsi. La retention deve essere **continua e automatica**: 1. **Cron giornaliero** che esegue la politica di retention di ogni tabella. 2. **Token di sicurezza** affinché il cron non sia attivabile dall'esterno. 3. **Log di esecuzione** per tracciare ciò che è stato eliminato. 4. **Notifica** in caso di errore o anomalia (volume di eliminazione anomalo). 5. **OPTIMIZE TABLE** settimanale sulle tabelle pulite per recuperare spazio disco (altrimenti InnoDB conserva lo spazio allocato). ## Il nostro modulo dfcleanup: il metodo pacchettizzato Implementare questa strategia a mano richiede due o tre giorni di sviluppo e altrettanti di test. [Il nostro modulo dfcleanup](https://www.datafirefly.com/it/product/dfcleanup-pulizia-base-prestashop/) per PrestaShop 8 e 9 industrializza tutto il metodo descritto qui: - **Sei cleaner specializzati**: ricerche, carrelli, log, statistiche, metadati orfani, immagini orfane. Ciascuno con la propria retention configurabile. - **Tre modalità**: Audit (sola lettura), Dry-run (simulazione tracciata), Execute (eliminazione a lotti di 5.000 righe). - **Guadagno in MB calcolato prima dell'azione**, per cleaner e totale. - **Cron protetto da token**, pronto all'uso. - **Log dettagliati** e compatibilità con PrestaShop 8 e 9. A 19 €, eviti le query DELETE a mano e installi una politica di retention duratura. Confrontato con il tempo di sviluppo e il costo di un incidente DBA, è uno dei moduli con il miglior ROI del catalogo. ## FAQ ### Bisogna fare un OPTIMIZE TABLE dopo ogni DELETE? No, non dopo ogni DELETE — è costoso in I/O e blocca la tabella. Una volta a settimana o al mese, in orario di scarso traffico, sulle tabelle che hanno subito una pulizia massiccia. `OPTIMIZE TABLE` recupera lo spazio disco che InnoDB non libera naturalmente dopo l'eliminazione. ### La pulizia può influenzare la SEO o le statistiche? Nessun impatto SEO: le tabelle pulite sono tecniche (ricerche interne, connessioni, log), non il catalogo né gli URL. Per le statistiche, se usi GA4 o Matomo, i tuoi dati sono memorizzati lì — il database PrestaShop è ridondante. Se usi le statistiche native di PS, configura una retention più lunga (180 giorni ad esempio). ### Quale retention per i carrelli abbandonati? 90 giorni bastano ampiamente. Gli strumenti di recupero carrello (mail, retargeting) si attivano nelle 24-72 ore. Oltre i 90 giorni, la probabilità di recupero è statisticamente nulla. E non elimini mai un carrello convertito in ordine — la join `ps_orders.id_cart` protegge questo dato. ### Quanto guadagno aspettarsi concretamente? Su un negozio attivo da 5 anni, con 2.000 visitatori al giorno, misuriamo in media una riduzione del 60-80% del database al primo passaggio. Un negozio da 12 GB scende a 3 o 4 GB. I passaggi successivi stabilizzano il database a un livello vicino al "peso reale di business". ### Il modulo è compatibile multi-negozio? Sì. I cleaner rispettano il perimetro multi-shop quando pertinente (carrelli, ricerche per negozio). Le tabelle globali (log, connessioni) sono pulite globalmente. ## Per approfondire Il debito di database è una delle tre principali fonti di degrado delle performance a lungo termine di un negozio PrestaShop, insieme ai moduli di terze parti obsoleti e alle immagini mal ottimizzate. Vedi anche la nostra [checklist Core Web Vitals 2026](https://www.datafirefly.com/it/2026/05/09/performance-prestashop-8-checklist-core-web-vitals-2026-lcp-inp-cls-2/) per il resto del quadro, e la [guida PrestaShop 9 vs 8](https://www.datafirefly.com/it/2026/05/01/prestashop-9-vs-prestashop-8-cambiamenti/) se prepari una migrazione: alleggerire il database prima della migrazione può dividere per 5 il tempo di switch. Per passare all'azione: [la nostra selezione di moduli per manutenzione, backup e affidabilità](https://www.datafirefly.com/it/solutions/prestashop/manutenzione-backup-affidabilita/) e [quella per accelerare il negozio](https://www.datafirefly.com/it/solutions/prestashop/performance-velocita/).