--- title: "Soluzione errore 1256 mysql \"data truncated for column\"" description: "Errore MySQL \"data truncated for column\" durante l'import di un dump: il codice reale è 1265, la causa è lo strict sql_mode, e la soluzione passa dall'allineamento tra ambienti." canonical: "https://www.mauriziofonte.it/blog/post/mysql-error-1256-data-truncated-for-column.html" author: "Maurizio Fonte" date: "2026-02-06T11:26:36+01:00" modified: "2026-06-15T18:01:26+02:00" section: "Database" tags: ["Database", "Business Continuity"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Database](https://www.mauriziofonte.it/blog/cat/database.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) # [Soluzione errore 1256 mysql "data truncated for column"](https://www.mauriziofonte.it/blog/post/mysql-error-1256-data-truncated-for-column.html) Venerdì 6 Febbraio 2026, alle 11:26 ![Soluzione errore 1256 mysql "data truncated for column"](https://www.mauriziofonte.it/image/000320200-mysql-error-1256-data-truncated-for-column.jpg) In un progetto di migrazione infrastrutturale per una PMI mi è capitato di seguire l'import di un dump MySQL da un server di produzione verso uno di backup, e di vederlo interrompersi a metà. Il conteggio delle righe importate non corrispondeva a quello della sorgente, e nei log comparivano decine di messaggi "Data truncated for column" durante l'esecuzione dell'import. È uno degli errori più comuni e, allo stesso tempo, più fraintesi quando si spostano dati fra ambienti MySQL configurati in modo diverso, e la sua diagnosi corretta non è quella che la maggior parte dei tutorial suggerisce. ## TL;DR > - **Errore reale:** MySQL **1265** `WARN_DATA_TRUNCATED` (SQLSTATE `01000`), spesso cercato e citato come "1256" (che è invece un errore diverso, legato alla decompressione). > - **Causa:** lo strict `sql_mode` (`STRICT_TRANS_TABLES` o `STRICT_ALL_TABLES`) promuove a errore bloccante la troncatura di un valore che eccede la colonna. Tipico quando importi un dump da un ambiente permissivo verso uno strict. > - **Fix corretto:** pulisci i dati alla sorgente (o allarga la colonna), rigenera il dump e reimporta con strict mode attivo. > - **Fix rapido per sbloccare l'import subito:** esegui `SET sql_mode='';` prima dell'import (o usa `INSERT IGNORE`), ma è un cerotto: i dati restano troncati. > - **Prevenzione:** stesso `sql_mode` e charset `utf8mb4` in tutti gli ambienti (sviluppo, staging, backup, produzione). ## Cos'è davvero l'errore "Data truncated for column" e quando compare? Partiamo da una precisazione utile, perché qui nasce la prima confusione. Questo errore viene spesso cercato e indicato come "errore 1256", ma il codice MySQL effettivo per "Data truncated for column" è il **1265** (`WARN_DATA_TRUNCATED`, SQLSTATE `01000`). Il codice 1256 è invece `ER_TOO_BIG_FOR_UNCOMPRESS`, legato a problemi di decompressione ZLIB e completamente estraneo alla troncatura dei dati di colonna. Conoscere il codice giusto è il primo passo per cercare la diagnosi corretta invece di inseguire piste sbagliate. Il messaggio canonico ha questa forma: ```text ERROR 1265 (01000) at line 683: Data truncated for column 'column_name' at row 10 ``` Lo SQLSTATE `01000` è la classe "Warning" dello standard SQL. In condizioni di default permissive, MySQL tratterebbe questa situazione come un avviso non bloccante: troncherebbe il valore al limite della colonna e proseguirebbe. Quando però il `sql_mode` include `STRICT_TRANS_TABLES` o `STRICT_ALL_TABLES`, l'avviso viene **promosso a errore vero e proprio** e lo statement viene abortito. Su tabelle InnoDB (transazionali) l'intero statement viene sottoposto a rollback; su tabelle MyISAM (non transazionali) la riga viene rifiutata e lo statement si interrompe. È esattamente questo meccanismo a far fallire un import che, su un altro server, era passato senza un singolo errore. ## Le cinque cause concrete della troncatura Le situazioni che fanno scattare il troncamento sono cinque, e vale la pena distinguerle perché la soluzione cambia a seconda della causa. **Prima causa: lunghezza dei dati eccessiva rispetto alla colonna.** È il caso più frequente. Una colonna `VARCHAR(50)` riceve un valore di 60 caratteri. Senza strict mode MySQL tronca a 50 e continua; con strict mode genera l'errore 1265 e aborta. **Seconda causa: incompatibilità di character set.** Una colonna definita con charset `latin1` riceve dati UTF-8 contenenti caratteri non rappresentabili. La sequenza di byte non si adatta al charset di destinazione e viene troncata al primo carattere problematico. Il caso più sottile è `utf8` contro `utf8mb4`: gli emoji e i caratteri CJK supplementari richiedono 4 byte, e una colonna `utf8mb3` (massimo 3 byte per carattere) li tronca. **Terza causa: valori ENUM non validi.** Una colonna `ENUM('Attivo', 'Inattivo', 'Sospeso')` riceve il valore `'Archiviato'`. Con strict mode è un errore 1265 immediato; senza strict mode MySQL inserisce una stringa vuota e genera un avviso silenzioso. **Quarta causa: perdita di precisione sui tipi numerici.** Un valore `2.987654321` su una colonna `DECIMAL(10,2)` viene troncato a `2.99` con arrotondamento. Lo standard SQL considera questa una "data adjustment" e non un "range error", quindi anche con strict mode non sempre genera 1265: dipende dalla versione e dall'entità del troncamento. È una sottigliezza che inganna, perché in molti danno per scontato che lo strict mode catturi qualsiasi troncatura, mentre l'adattamento numerico al tipo di destinazione è un'operazione esplicitamente permessa dallo standard. **Quinta causa: caratteri nascosti negli import CSV.** Un caso particolarmente subdolo è l'import di CSV generati su Windows che usano `\r\n` come terminatore di riga dove MySQL si aspetta un `\n` puro. Il `\r` resta attaccato al valore importato e, su colonne con vincoli esatti come gli `ENUM`, provoca una troncatura perché non corrisponde a nessun valore atteso. ## La diagnosi corretta su un import tra ambienti Il contesto tipico di questo errore è proprio quello dell'import di un dump da un server di produzione, con `sql_mode` permissivo, verso un server di backup con `sql_mode` strict. Le righe della tabella sorgente contengono valori che erano stati inseriti in produzione senza i vincoli che il server di destinazione applica. L'errore 1265 si manifesta perché il server strict rifiuta gli stessi dati che la sorgente aveva accettato silenziosamente, troncandoli. Il pattern di disallineamento di configurazione fra origine e destinazione è il classico generatore di questi sintomi, e capirlo indirizza subito verso la soluzione giusta. Se gestisci import e migrazioni MySQL fra ambienti e ti trovi con conteggi di righe che non tornano, è esattamente il tipo di problema su cui intervengo: nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su audit della configurazione MySQL, allineamento di `sql_mode` e charset fra ambienti, e migrazione di dati legacy con normalizzazione automatica. La soluzione operativa è una di queste tre, in ordine di preferibilità ingegneristica. **Soluzione 1, raccomandata: correggere i dati alla sorgente.** Si identificano le righe che eccedono i vincoli, si normalizzano (riducendo i valori al limite della colonna o, se i dati sono legittimi, allargando la colonna stessa), si rigenera il dump dalla sorgente pulita e si importa nel server di destinazione con lo strict mode invariato. È la soluzione che risolve il problema invece di nasconderlo. **Soluzione 2: rilassare temporaneamente il sql_mode per il solo import.** Si esegue `SET sql_mode='';` (o si rimuovono i token strict) all'inizio della sessione di import, lasciando invariata la configurazione globale del server. È un approccio chirurgico, valido per sbloccare rapidamente, ma va usato sapendo che i dati che superano i vincoli verranno comunque troncati: è un modo per completare l'import, non per garantire l'integrità dei dati. **Soluzione 3: usare INSERT IGNORE.** Modificando il dump per usare `INSERT IGNORE` al posto di `INSERT`, le troncature tornano a essere avvisi anche in strict mode e l'import procede. È la meno consigliabile, perché maschera il problema lasciando in tabella dati silenziosamente troncati che possono diventare bug funzionali più avanti. Quella che applico quasi sempre nei progetti di consulenza è la prima. Il principio operativo è semplice: se il `sql_mode` del server di destinazione è strict per scelta, e da MySQL 8 lo è di default, e l'import fallisce, il messaggio è che la sorgente contiene dati che non avrebbero dovuto essere accettati. Aggirare il problema rendendo permissiva la destinazione significa replicarvi gli stessi difetti di qualità dei dati della sorgente. La via corretta è risalire all'origine, capire quale vincolo era stato indebolito in passato, pulire i dati e ripristinarlo. ## Come trovare le righe che causano la troncatura Prima di scegliere la soluzione conviene sapere esattamente quali dati stanno troncando, perché intervenire alla cieca porta a tagliare valori legittimi. Lo strumento più immediato è `SHOW WARNINGS` subito dopo lo statement che ha generato l'avviso: in modalità non-strict MySQL non aborta ma accumula gli avvisi, e questo comando li elenca riga per riga, indicando colonna e posizione. È il modo più rapido per ottenere l'inventario completo dei problemi in un colpo solo, eseguendo l'import una volta con strict mode disattivato proprio a scopo diagnostico, leggendo gli avvisi, e solo dopo decidendo come correggere. Quando il sospetto è la lunghezza, si interroga direttamente la sorgente per stanare i valori che eccedono la definizione della colonna, così da quantificare il problema prima di toccarlo: ```sql -- Trova i valori più lunghi del limite della colonna (es. VARCHAR(50)) SELECT id, CHAR_LENGTH(nome) AS lunghezza, nome FROM clienti WHERE CHAR_LENGTH(nome) > 50 ORDER BY lunghezza DESC; ``` Per i caratteri nascosti, come il `\r` degli import CSV provenienti da Windows, una verifica mirata con `HEX()` su un campione rivela i byte di controllo che a occhio non si vedono. Questa fase diagnostica è quella che distingue una correzione consapevole da una rimozione cieca dei vincoli: una volta che sai quante righe e quali colonne sono coinvolte, capisci se hai davanti pochi record sporchi da ripulire a mano o un problema strutturale di definizione delle colonne che richiede una modifica dello schema. ## Un equivoco frequente da chiarire: NO_AUTO_VALUE_ON_ZERO Vale la pena chiarire un punto, perché è una fonte di confusione ricorrente in rete. Molte guide indicano il token `NO_AUTO_VALUE_ON_ZERO` di `sql_mode` come responsabile di questo errore. Non lo è. `NO_AUTO_VALUE_ON_ZERO` controlla esclusivamente il comportamento delle colonne `AUTO_INCREMENT` quando ricevono il valore esplicito zero: con il default di MySQL inserire zero genera il prossimo numero di sequenza esattamente come inserire `NULL`; con questo token attivo, zero resta zero e solo `NULL` genera il prossimo valore. È una modalità pensata per i dump: se una tabella ha valori zero in colonne `AUTO_INCREMENT`, `mysqldump` inserisce automaticamente `SET sql_mode='NO_AUTO_VALUE_ON_ZERO';` proprio per preservarli al reimport. Con la troncatura dei dati non ha nulla a che fare: è una protezione ortogonale, dedicata a un problema diverso. La confusione nasce solo dal fatto che entrambi i token vivono nel parametro `sql_mode` e compaiono nei contesti di dump e import. ## Best practice 2026 per evitare i disallineamenti tra ambienti Quattro regole operative che applico nelle infrastrutture MySQL dei clienti per non ritrovarsi in queste situazioni. **Standardizza il sql_mode tra tutti gli ambienti.** Sviluppo, staging, backup e produzione devono condividere lo stesso `sql_mode`. La policy che applico di default è `STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO`: è la configurazione più vicina allo standard SQL e cattura in fase di sviluppo i problemi di qualità dei dati che altrimenti si accumulano fino a manifestarsi durante un upgrade o una migrazione. La [documentazione ufficiale MySQL sul sql_mode](https://dev.mysql.com/doc/en/sql-mode.html) è il riferimento autoritativo per ogni token. **Unifica il charset a utf8mb4 ovunque.** Il vecchio `utf8` di MySQL, alias di `utf8mb3`, supporta solo i caratteri Unicode fino al Basic Multilingual Plane e tronca emoji, simboli matematici avanzati e ideogrammi CJK supplementari. Il moderno `utf8mb4` copre l'intero Unicode, e per i progetti nuovi nel 2026 non c'è alcuna ragione tecnica per usare altro, sia a livello server sia a livello di tabella e colonna. La migrazione da `utf8` a `utf8mb4` è uno degli interventi più frequenti che faccio negli audit, e si collega alla [diagnosi delle connessioni lente MySQL su VPS](https://www.mauriziofonte.it/blog/post/diagnosi-risoluzione-connessioni-lente-mysql-vps.html). **Per i database grandi, backup binario invece del dump testuale.** Sopra dimensioni rilevanti o per applicazioni mission-critical, il dump testuale con `mysqldump` diventa lento e suscettibile esattamente a questa classe di problemi in fase di reimport. La strategia che documento nella guida ai [backup incrementali di MySQL con XtraBackup senza blocchi](https://www.mauriziofonte.it/blog/post/backup-incrementale-mysql-xtrabackup-recovery-point-senza-blocchi.html) sposta il problema su un livello diverso: backup fisici coerenti e recovery point granulari, senza ri-esecuzione di `INSERT` che possano fallire per troncatura. **Valida i dati a livello applicativo, non solo nel database.** Nei progetti PHP e Laravel moderni non delego al database la validazione di lunghezza, formato e charset: la validazione avviene al confine dell'applicazione (FormRequest in Laravel, Constraint in Symfony), prima dell'`INSERT`. Il database resta l'ultima linea di difesa per l'integrità referenziale, ma i vincoli di lunghezza e tipo vengono catturati dall'applicazione con messaggi espliciti per l'utente. Questo riduce drasticamente la superficie di problemi che si manifestano come errore 1265 in produzione, perché i dati che arrivano al database sono già normalizzati. Una nota importante su MySQL 8: dalla versione 8.0 lo strict mode è il default operativo, con `STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION` di serie. Significa che ogni installazione fresca ha già strict mode attivo, e nelle migrazioni da MySQL 5.7 a 8.0 il codice che funzionava silenziosamente con troncatura sotto la 5.7 inizia a fallire con l'errore 1265. È una delle fonti più frequenti di intoppi in quelle migrazioni, ed è esattamente la classe di problemi che lo strict mode è progettato per esporre: la soluzione corretta non è disattivarlo dopo l'upgrade, ma cogliere l'occasione per pulire i dati e i vincoli che sta giustamente segnalando. I riferimenti che consulto per la diagnostica sono il [manuale ufficiale degli error code MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html) e la pagina sul `sql_mode` già citata. Per chi gestisce database MySQL in produzione e si trova periodicamente con import che falliscono, valori troncati o disallineamenti silenziosi fra produzione e backup, [contattami per un confronto diretto](https://www.mauriziofonte.it/pages/contattami): di solito basta un audit della configurazione di tutti gli ambienti e di un campione rappresentativo dei dati per costruire un piano di pulizia e standardizzazione che elimina questa intera classe di problemi una volta per tutte. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Lunedì 15 Giugno 2026, alle 18:01 [« Articolo precedenteMulti-tenancy in Laravel: strategie di isolamento dati per SaaS PHP6 Febbraio 2026](https://www.mauriziofonte.it/blog/post/multi-tenancy-laravel-strategie-isolamento-dati-saas-php.html)[Articolo successivo »Feature flag production-ready in PHP: rollout graduale senza rischi di regressione9 Febbraio 2026](https://www.mauriziofonte.it/blog/post/feature-flag-production-ready-php-rollout-graduale-senza-regressioni.html) ### Articoli correlati a Soluzione errore 1256 mysql "data truncated for column" - [Migrazione del codice legacy: perché non puoi affidarti a un consulente generico](https://www.mauriziofonte.it/blog/post/migrazione-codice-legacy-rischi-consulenza-generica.html) Migrare un'applicazione legacy non è "aggiornare la versione di PHP": è gestire cambi di comportamento silenziosi, un livello dati fragile e · 16 Mag 2025 ![Migrazione del codice legacy: perché non puoi affidarti a un consulente generico](https://www.mauriziofonte.it/image/001040070-migrazione-codice-legacy-rischi-consulenza-generica.jpg) - [Sincronizzare le identità Zitadel tra più ambienti senza trascinare il database](https://www.mauriziofonte.it/blog/post/zitadel-sincronizzazione-identita-cross-ambiente.html) Quando colleghi un'applicazione a un identity provider, ogni utente locale guadagna una colonna con l'identificativo esterno. Quella colonna · 12 Agosto 2026 ![Sincronizzare le identità Zitadel tra più ambienti senza trascinare il database](https://www.mauriziofonte.it/image/005570070-zitadel-sincronizzazione-identita-cross-ambiente.jpg) - [Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026](https://www.mauriziofonte.it/blog/post/porting-funzioni-mysql-verso-mysqli-php.html) Le funzioni mysql di PHP sono deprecate dalla 5.5 e rimosse dalla 7.0. Un'applicazione che le contiene ancora gira per forza su una versione · 20 Mag 2026 ![Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026](https://www.mauriziofonte.it/image/000290070-porting-funzioni-mysql-verso-mysqli-php.jpg) - [Creazione di un database IP-to-Country](https://www.mauriziofonte.it/blog/post/creazione-database-ip-to-country.html) Mappare un indirizzo IP al suo paese è ancora utile, per servire la lingua giusta, per analytics o per regole di accesso. Ma il modo in cui si · 27 Aprile 2026 ![Creazione di un database IP-to-Country](https://www.mauriziofonte.it/image/000200070-creazione-database-ip-to-country.jpg) - [Refactoring database MySQL su Laravel: report da 47 minuti a 11 secondi senza upgrade hardware](https://www.mauriziofonte.it/blog/post/rifacimento-strategico-database-mysql-laravel.html) Un database MySQL da 12 GB su un VPS Contabo, un report mensile che impiegava 47 minuti, 38 indici su una tabella di cui 12 mai utilizzati, e · 26 Giugno 2025 ![Refactoring database MySQL su Laravel: report da 47 minuti a 11 secondi senza upgrade hardware](https://www.mauriziofonte.it/image/001870070-rifacimento-strategico-database-mysql-laravel.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Soluzione errore 1256 mysql "data truncated for column"", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/mysql-error-1256-data-truncated-for-column.html Pubblicato: 2026-02-06 · Aggiornato: 2026-06-15. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.