1 08/05/2026 7 min

Se devi salvare struttura e dati di una tabella MySQL, il comando giusto dipende da tre cose: dimensione della tabella, tolleranza al lock e necessità di ottenere un dump ripristinabile senza sorprese. In pratica, per una tabella singola la soluzione più lineare resta mysqldump, ma va usato con opzioni coerenti con il motore, il carico e il tipo di backup che ti serve davvero.

Comando base per esportare schema e dati

Per salvare una tabella completa, struttura compresa, il comando essenziale è questo:

mysqldump -u nome_utente -p nome_database nome_tabella > nome_tabella.sql

Questo produce un file SQL con CREATE TABLE, eventuali indici, vincoli e tutte le righe presenti al momento dell’export. È il punto di partenza corretto se vuoi migrare, clonare o mettere al sicuro una tabella prima di una modifica.

Se la tabella è piccola e il carico è basso, il comando sopra basta. Se invece sei in produzione, conviene aggiungere opzioni che riducano problemi di consistenza, compatibilità e lock.

Opzioni che contano davvero in produzione

Per una tabella InnoDB, il punto chiave è ottenere un dump coerente senza bloccare troppo il servizio. Una variante più robusta è questa:

mysqldump -u nome_utente -p \
  --single-transaction \
  --quick \
  --routines=false \
  --triggers \
  nome_database nome_tabella > nome_tabella.sql

--single-transaction apre una transazione consistente e riduce il lock sulle tabelle InnoDB. --quick evita di caricare tutto in RAM lato client. --triggers include i trigger collegati alla tabella, se presenti. --routines=false qui è solo per chiarezza: su un dump di singola tabella in genere non serve portarsi dietro routine del database intero.

Se la tabella usa MyISAM o un motore non transazionale, --single-transaction non ti dà la stessa garanzia. In quel caso devi scegliere tra consistenza e impatto: o accetti un breve lock, o programmi il dump in una finestra di manutenzione.

Salvare solo struttura, solo dati, o entrambi

Ci sono casi in cui non serve tutto. MySQL ti permette di separare schema e contenuto con precisione, utile quando vuoi versionare la struttura o rifare i dati altrove.

Solo struttura:

mysqldump -u nome_utente -p --no-data nome_database nome_tabella > nome_tabella_schema.sql

Solo dati:

mysqldump -u nome_utente -p --no-create-info nome_database nome_tabella > nome_tabella_data.sql

Schema e dati:

mysqldump -u nome_utente -p nome_database nome_tabella > nome_tabella_full.sql

Questa distinzione è utile anche per il controllo delle release: lo schema può stare nel repository, i dati restano nel backup operativo. Mischiare le due cose senza criterio complica sia il restore sia il diff tra ambienti.

Tabella grande: evitare dump fragili o ingestibili

Quando la tabella cresce, il problema non è solo il tempo di esecuzione: entrano in gioco spazio disco, I/O, timeout della sessione e dimensione del file risultante. In questi casi conviene usare un flusso più prudente.

Una configurazione pratica per tabelle grandi è comprimere al volo l’output:

mysqldump -u nome_utente -p --single-transaction --quick nome_database nome_tabella | gzip > nome_tabella.sql.gz

Questo riduce spazio su disco e spesso accelera il trasferimento verso storage remoto. Il compromesso è che il file non è immediatamente leggibile in chiaro, ma resta ripristinabile in modo semplice.

Se vuoi evitare che la shell tenga tutto in una pipe lunga e fragile, puoi scrivere su file temporaneo e comprimere dopo. In ambienti sensibili è spesso meglio avere un passaggio esplicito in più, perché rende più chiari i punti di controllo e i log di errore.

Ripristino della tabella: il test che conta davvero

Un dump vale solo se si riesce a ripristinare. Prima di considerarlo buono, verifica che il file SQL sia effettivamente importabile su un database di test o su una istanza temporanea.

Ripristino base:

mysql -u nome_utente -p nome_database < nome_tabella.sql

Se il dump è compresso:

gunzip -c nome_tabella.sql.gz | mysql -u nome_utente -p nome_database

Il controllo minimo non è “il comando finisce”, ma “la tabella torna con struttura e numero di righe atteso”. Per questo, dopo il restore, confronta almeno il conteggio record e la presenza degli indici principali.

Verifiche prima del dump

Prima di esportare, controlla tre cose: motore, dimensione e spazio libero. Sono i classici dettagli che saltano fuori quando il backup fallisce a metà.

Motore della tabella:

SELECT ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'nome_database'
  AND TABLE_NAME = 'nome_tabella';

Dimensione della tabella:

SELECT table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'nome_database'
  AND TABLE_NAME = 'nome_tabella';

Spazio disco disponibile:

df -h

Se il file finale deve stare sullo stesso host del database, considera margine abbondante: un dump SQL può crescere molto più dei dati “grezzi”, soprattutto con testo lungo, apici escapati e istruzioni DDL aggiuntive.

Gestione di lock e consistenza

Molti problemi non nascono dal comando in sé, ma dal contesto. Su una tabella attiva, un dump sbagliato può rallentare query critiche o produrre un file incoerente. Se la tabella è InnoDB, --single-transaction è quasi sempre la prima scelta. Se invece hai tabelle non transazionali, devi ragionare in termini di finestra operativa.

In ambienti con carico reale, è utile fare un test con una tabella simile in staging e osservare:

  1. tempo di dump;
  2. eventuali lock visibili in SHOW PROCESSLIST;
  3. impatti su latenza applicativa e query lente;
  4. dimensione finale del file e tempo di restore.

Se il dump impatta gli utenti, la mitigazione non è “rifare il comando più piano” in astratto: o sposti l’operazione fuori fascia, o la esegui su replica, o riduci il perimetro del backup al minimo necessario.

Escludere dati superflui senza perdere ripristinabilità

In alcune tabelle ci sono colonne o righe che non vuoi salvare integralmente, ad esempio dati temporanei, cache applicative o contenuti derivabili. In quel caso puoi filtrare l’export con attenzione, ma devi sapere che stai creando un backup parziale, non un clone perfetto.

Esempio con clausola --where:

mysqldump -u nome_utente -p nome_database nome_tabella \
  --where="created_at >= '2025-01-01'" > nome_tabella_filtrata.sql

Questa tecnica va usata con disciplina, perché il restore potrebbe fallire a livello logico se la tabella ha relazioni con altre tabelle non esportate. Se esporti un sottoinsieme, documenta sempre il criterio usato.

Alternative a mysqldump quando serve più controllo

mysqldump è lo strumento standard, ma non è l’unico. Per ambienti molto grandi o backup frequenti, alcuni team preferiscono strumenti fisici o soluzioni che supportano snapshot consistenti e restore più veloci. Il vantaggio è il tempo; lo svantaggio è la portabilità e la complessità operativa.

Se ti serve solo una tabella e vuoi restare in SQL puro, però, il vantaggio pratico di mysqldump resta forte: il file è leggibile, versionabile, trasferibile e importabile con strumenti standard. Per molte attività di manutenzione è esattamente quello che serve.

Workflow consigliato in pratica

Un flusso sensato per mettere al sicuro una tabella è questo:

  1. verifica motore e dimensione con information_schema;
  2. controlla spazio libero con df -h;
  3. esegui il dump con --single-transaction se la tabella è InnoDB;
  4. comprimi se il file è grande;
  5. prova il restore su un database di test;
  6. confronta conteggio righe, struttura e indici.

Questo approccio evita l’errore classico: fare il dump, archiviarlo e accorgersi al bisogno che il file è incompleto, corrotto o troppo pesante da ripristinare in tempi utili.

Snippet utile per automatizzare il backup di una tabella

Se vuoi schedulare il salvataggio, puoi mettere il comando in uno script shell minimale. L’obiettivo non è fare un framework, ma avere log chiari e un punto unico dove inserire rotazione e controllo errori.

#!/bin/sh
set -eu

DB="nome_database"
TABLE="nome_tabella"
OUTDIR="/backup/mysql"
TS=$(date +%F_%H%M%S)
FILE="$OUTDIR/${DB}_${TABLE}_${TS}.sql.gz"

mkdir -p "$OUTDIR"
mysqldump -u nome_utente -p --single-transaction --quick "$DB" "$TABLE" | gzip > "$FILE"

Questo script è volutamente semplice. In produzione conviene sostituire la password a prompt con un metodo sicuro, ad esempio un file di opzioni con permessi stretti o un secret manager, evitando credenziali in chiaro nello script.

Controllo finale: cosa deve esserci nel file

Un dump corretto di tabella singola dovrebbe contenere almeno:

  • l’istruzione CREATE TABLE;
  • gli INSERT o i dati esportati in formato equivalente;
  • eventuali trigger collegati;
  • commenti e metadati utili al restore, se richiesti dal tuo scenario.

Se uno di questi pezzi manca, non assumere che il backup sia valido solo perché il file esiste. Aprilo, cerca i marker SQL attesi e fai un restore di prova. È il controllo più banale, ma anche quello che salva più incidenti quando serve davvero recuperare i dati.