{"id":21231,"date":"2026-09-01T11:49:31","date_gmt":"2026-09-01T09:49:31","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-instant-add-column-ohne-downtime-schemaupdate-datenbank\/"},"modified":"2026-09-01T11:49:31","modified_gmt":"2026-09-01T09:49:31","slug":"mariadb-aggiunta-immediata-di-una-colonna-senza-tempi-di-inattivita-aggiornamento-dello-schema-del-database","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/mariadb-instant-add-column-ohne-downtime-schemaupdate-datenbank\/","title":{"rendered":"MariaDB Instant ADD COLUMN: modifiche allo schema senza tempi di inattivit\u00e0 per i database moderni"},"content":{"rendered":"<p>Con Instant ADD COLUMN, MariaDB offre una tecnica che mi permette di aggiungere nuove colonne in grandi tabelle InnoDB in tempo reale, senza blocchi significativi e senza tempi di inattivit\u00e0. L'algoritmo INSTANT non riscrive i dati, ma si limita ad ampliare <strong>Metadati<\/strong> e in questo modo genera nuove colonne con valori predefiniti.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<p>I seguenti punti chiave mi aiutano a valutare rapidamente le possibilit\u00e0 offerte dalle operazioni istantanee e a prendere le decisioni giuste per i sistemi produttivi. Riassumo gli aspetti pi\u00f9 importanti e li metto in relazione con le attivit\u00e0 amministrative tipiche. Dall\u2019interazione tra versione, struttura delle tabelle e strategia DDL deduco azioni concrete da intraprendere. L\u2019elenco funge da promemoria sintetico per l\u2019attivit\u00e0 quotidiana <strong>Database<\/strong> Amministrazione. Dopo aver fornito una panoramica generale, approfondir\u00f2 gli aspetti relativi all'implementazione, alle insidie e agli esempi pratici.<\/p>\n\n<ul>\n  <li><strong>Tempi di inattivit\u00e0<\/strong> Ridurre al minimo: nuove colonne in pochi millisecondi senza ricostruzioni n\u00e9 operazioni di copia.<\/li>\n  <li><strong>DDL online<\/strong> Controllo sicuro: specificare esplicitamente ALGORITHM=INSTANT e LOCK=NONE.<\/li>\n  <li><strong>Versione<\/strong> Nota: nella versione 10.3 solo l'ultima colonna; a partire dalla versione 10.4, posizioni flessibili e altro ancora.<\/li>\n  <li><strong>Metadati<\/strong> anzich\u00e9 dati: nessuna riscrittura fisica, fornire valori predefiniti in modo logico.<\/li>\n  <li><strong>Scala<\/strong> Semplificare: minore ritardo nella replica e implementazioni pianificabili.<\/li>\n<\/ul>\n\n<p>Questi punti danno i loro frutti solo quando controllo le compatibilit\u00e0, come ROW_FORMAT o gli indici speciali, e le verifico tramite test. In questo modo mantengo gestibili le modifiche alle tabelle di grandi dimensioni e riesco a far fronte anche ai picchi di carico <strong>in grado di agire<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-schemaaenderung-1456.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perch\u00e9 Instant ADD COLUMN cambia le regole del gioco<\/h2>\n\n<p>Un tempo, un classico <code>ALTER TABLE ... ADD COLUMN<\/code> spesso operazioni di copia che durano ore, blocchi del sistema e un rallentamento tangibile <strong>Tempi di inattivit\u00e0<\/strong>. Ci\u00f2 non si adattava bene ai rilasci agili e alle applicazioni attive 24 ore su 24, 7 giorni su 7, in cui ogni finestra di manutenzione comporta costi elevati. Con l\u2019algoritmo INSTANT, lo sforzo si sposta dal livello dei dati a quello del catalogo, rendendo le modifiche estremamente veloci anche con miliardi di righe. Posso rendere disponibili nuovi attributi in tempo reale senza interrompere il carico di lavoro in corso. Questo mi offre la libert\u00e0 di effettuare iterazioni rapide e <strong>Rilascio<\/strong>-Frequenza di clock.<\/p>\n\n<p>Dal punto di vista operativo, i rischi e gli sforzi di coordinamento diminuiscono, poich\u00e9 non devo pi\u00f9 pianificare grandi interventi di modifica. Questo approccio ha un impatto diretto sulla replica, sulle finestre di backup e sul funzionamento delle applicazioni. Laddove in passato un team coordinava interventi notturni, oggi spesso \u00e8 sufficiente una breve modifica con un piano di implementazione ben definito. Questo mi permette di testare pi\u00f9 rapidamente le idee di prodotto e di renderle operative. In questo modo, la manutenzione del database si trasforma in un <strong>Leve di crescita<\/strong>.<\/p>\n\n<h2>Ecco come funziona l\u2019algoritmo INSTANT \u201cdietro le quinte\u201d<\/h2>\n\n<p>Il concetto di base \u00e8 semplice: InnoDB estende la descrizione della tabella e aggiunge una voce speciale nell\u2019indice cluster, invece di intervenire fisicamente su ogni riga. In questo modo le nuove colonne esistono a livello logico e, durante la lettura, il motore restituisce il valore predefinito oppure un valore memorizzato <strong>Valore<\/strong>. Questa modifica richiede un tempo di O(1) rispetto al numero di record, poich\u00e9 non vengono riscritte nuove pagine. Gli indici secondari rimangono invariati, il che evita un carico aggiuntivo di operazioni di I\/O. Ne traggo vantaggio grazie a blocchi di durata minima, I\/O ridotto al minimo e dimensioni molto ridotte <strong>Transazioni<\/strong>.<\/p>\n\n<p>Non appena inserisco dei dati nella nuova colonna, InnoDB salva questi valori come di consueto. Fino a quel momento si tratta solo di un\u2019espansione virtuale della struttura. Proprio per questo motivo \u00e8 possibile estendere molti schemi di produzione senza causare interruzioni del servizio. Tengo presente che determinate combinazioni di formati e funzionalit\u00e0 possono impedire l\u2019Instant. Un rapido controllo preventivo mi evita problemi successivi <strong>Sorprese<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_schema_aenderung_2843.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Versioni, formati e limiti<\/h2>\n\n<p>In MariaDB 10.3 posso aggiungere la nuova colonna solo alla fine della tabella in modo istantaneo; se specifico una posizione, l'operazione ricorre a un algoritmo pi\u00f9 lento. A partire da MariaDB 10.4, un formato dati esteso consente inserimenti praticamente in qualsiasi punto, l'esecuzione istantanea di DROP COLUMN e la modifica dell'ordine delle colonne. Sono incompatibili determinati formati di riga come <code>ROW_FORMAT=COMPRESSED<\/code>, e gli indici speciali possono comportare alcune limitazioni. Verifico inoltre se <code>innodb_instant_alter_column_allowed<\/code> limita il comportamento. Solo quando la versione, il formato e le variabili corrispondono, INSTANT mi fornisce il risultato sperato <strong>Benefici<\/strong>.<\/p>\n\n<p>\u00c8 utile fare una rapida verifica della realt\u00e0: <code>SELECT VERSION();<\/code>, <code>SHOW CREATE TABLE ...;<\/code> e un secco <code>ALTER TABLE ... ADD COLUMN ... ALGORITHM=INSTANT, LOCK=NONE;<\/code> nell'ambiente di staging. Se vedo un messaggio di errore, blocco la modifica sull'ambiente di produzione e modifico il design o le opzioni. In questo modo evito ricostruzioni indesiderate e i conseguenti picchi di carico. Soprattutto con tabelle molto grandi, questa precauzione si rivela utile. Preferisco decidere in fase di test piuttosto che sotto <strong>Stampa di produzione<\/strong>.<\/p>\n\n<h2>I limiti in dettaglio: tipi di dati, valori predefiniti e casi particolari<\/h2>\n\n<p>Affinch\u00e9 INSTANT funzioni, le definizioni delle colonne devono rispettare determinate regole. Si \u00e8 dimostrata valida la seguente regola empirica: <strong>impostazioni predefinite semplici e costanti<\/strong> funzionano, mentre le espressioni complesse spesso no. Quindi inserisco <code>DEFAULT NULL<\/code> oppure un valore letterale ben definito (numero, stringa), evitando per\u00f2 chiamate a funzioni come <code>NOW()<\/code>, <code>UUID()<\/code> o espressioni dipendenti. Per i tipi di testo e di tipo blob valgono ulteriori restrizioni a seconda della versione; non mi affido al mio istinto, ma eseguo dei test con un dump di staging realistico.<\/p>\n\n<p>Non tutti i tipi di attributo sono adatti a un avvio \u201eistantaneo\u201c: una colonna con <code>AUTO_INCREMENT<\/code> introdurre, e subito dopo anche un <strong>Indice unico<\/strong> costruirli o inserirli direttamente in un <strong>Chiave esterna<\/strong> L'uso di questa opzione porta rapidamente fuori dal percorso \"Instant\". In questi casi, suddivido la modifica in pi\u00f9 passaggi: prima la colonna (INSTANT), poi l'indice\/il vincolo (in genere INPLACE). <strong>Generati<\/strong> oppure <strong>virtuale<\/strong> Le colonne le controllo separatamente; a seconda del formato di stampa e del motore, vengono utilizzati algoritmi diversi. Il set di caratteri e <strong>Collazione<\/strong> Lo specifico espressamente per evitare sorprese successive nell'ordinamento o nei confronti.<\/p>\n\n<p>Anche <strong>Modifiche di posizione<\/strong> dipendono dalla versione: nella 10.3 devo posizionare le colonne alla fine, mentre dalla 10.4 in poi ho praticamente mano libera. Ciononostante, faccio attenzione agli ORM e agli strumenti che indirizzano le colonne tramite posizione ordinale: in questi casi, anche uno spostamento senza copia dei dati pu\u00f2 causare errori logici. Pertanto, pianifico la posizione non solo dal punto di vista tecnico, ma anche tenendo conto del codice dell\u2019applicazione.<\/p>\n\n<h2>Migliori pratiche: implementazione sicura<\/h2>\n\n<p>Formulo sempre le DDL in modo esplicito per evitare soluzioni di ripiego poco chiare. Con <code>ALGORITMO=ISTANTANEO<\/code> e <code>BLOCCO=NESSUNO<\/code> costringo MariaDB a utilizzare la variante veloce oppure ottengo un errore evidente. La colonna <code>NOT NULL<\/code>, imposto un valore predefinito appropriato, in modo che le vecchie righe siano logicamente corrette <strong>Valori<\/strong> fornire. Prima del rollout, misuro le latenze di staging, il comportamento di replica e la durata dei lock. Inoltre, registro accuratamente la modifica nel change log del <strong>Banca dati<\/strong>.<\/p>\n\n<p>Alcuni esempi pratici sono di grande aiuto nella pratica: <code>ALTER TABLE orders ADD COLUMN marketing_tag VARCHAR(40) DEFAULT '' NOT NULL ALGORITHM=INSTANT, LOCK=NONE;<\/code>. Oppure per la versione 10.4+: <code>ALTER TABLE users ADD COLUMN plan INT DEFAULT 0 NOT NULL AFTER status ALGORITHM=INSTANT, LOCK=NONE;<\/code>. In entrambi i casi, verifico preventivamente che le opzioni della tabella abbiano un ROW_FORMAT compatibile. Durante l'esecuzione, tengo d'occhio metriche come Threads_running e I\/O. Dopo la modifica, verifico le query che utilizzano immediatamente la nuova colonna <strong>utilizzare<\/strong>.<\/p>\n\n<h2>Modelli di migrazione sicuri con backfill e indici<\/h2>\n\n<p>Negli ambienti di produzione lavoro con <strong>a due stadi<\/strong> Modifiche. Passo 1: aggiungere la colonna \"instant\", innanzitutto <code>NULL<\/code>-compatibile e con un\u2019impostazione predefinita chiara. Fase 2: aggiornare l\u2019applicazione tramite feature flag, in modo che le nuove operazioni di scrittura riempiano gi\u00e0 la colonna, mentre i dati preesistenti rimangano vuoti. Il <strong>Riempimento<\/strong> lo eseguo in modo asincrono in piccoli batch, ad esempio tramite un worker che utilizza <code>UPDATE ... WHERE new_col \u00c8 NULL ORDER BY pk LIMIT N<\/code> e inserisce delle pause tra le esecuzioni. In questo modo il carico rimane controllabile.<\/p>\n\n<p>Se ho bisogno di un indice secondario sulla nuova colonna, lo separo dall'aggiunta della colonna. La creazione dell'indice avviene solitamente <strong>INPLACE<\/strong>, ma richiede un tempo proporzionale alla quantit\u00e0 di dati. Grazie a questa separazione, evito che la rapida modifica dello schema fallisca a causa di lunghe operazioni di indicizzazione. Solo una volta completato il backfill, eseguo facoltativamente un <code>NOT NULL<\/code>-passo dopo passo \u2013 ma solo se l'algoritmo lo consente senza necessit\u00e0 di una ricostruzione. Per i rollback spesso \u00e8 sufficiente disattivare il feature flag e lasciare la colonna inattiva fino a quando non viene pianificato uno smantellamento completo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-schema-change-downtime-f5b7.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Prestazioni e replica<\/h2>\n\n<p>Le operazioni istantanee riducono il carico di lavoro che le repliche devono sostenere, poich\u00e9 non vengono eseguite operazioni di copia su larga scala. Ci\u00f2 riduce il rischio di ritardi percepibili e alleggerisce il carico dei processi in esecuzione in parallelo <strong>Domande<\/strong>. In ambienti con pi\u00f9 sedi o configurazioni a cascata, questo aspetto riveste un ruolo fondamentale per gli obiettivi RTO\/RPO. Chi dispone di soluzioni adeguate <a href=\"https:\/\/webhosting.de\/it\/topologie-di-replica-dei-database-configurazione-di-cluster-di-hosting-scalabilita-dei-database\/\">Topologie di replica<\/a> \u00e8 in grado di applicare le modifiche in modo mirato e di strutturare chiaramente i rollback. In questo modo il sistema rimane stabile anche nei momenti di picco di traffico <strong>reattivo<\/strong>.<\/p>\n\n<p>Tuttavia, tengo conto dei formati dei log binari e delle dimensioni degli eventi per evitare effetti collaterali. In caso di volume di scrittura molto elevato, controllo lo stato degli slave e la latenza dei thread SQL durante la modifica. Chi necessita di attivit\u00e0 di auditing pu\u00f2 evidenziare la modifica DDL tramite il log tagging. I processi ETL a valle dovrebbero essere informati tempestivamente della nuova colonna, in modo che le esecuzioni notturne non risultino inutili. Questa orchestrazione garantisce un funzionamento affidabile <strong>Processi<\/strong>.<\/p>\n\n<h2>Caratteristiche specifiche di Galera\/Cluster con Instant-DDL<\/h2>\n\n<p>Nei cluster con replica sincrona (ad es. Galera), le operazioni DDL spesso agiscono come <strong>TOI<\/strong>-Evento (Total Order Isolation). INSTANT riduce notevolmente il coordinamento globale necessario a tal fine, ma pu\u00f2 comunque verificarsi una breve pausa a livello di cluster. Per questo motivo continuo a pianificare consapevolmente tali modifiche, mantengo brevi le sessioni ed evito transazioni simultanee di lunga durata che <strong>MDL<\/strong>-potrebbero prolungare i periodi di blocco. Ricorro alle strategie RSU (Rolling Schema Upgrade) solo in casi specifici, quando \u00e8 strettamente necessario dal punto di vista tecnico: il sovraccarico operativo \u00e8 solitamente superiore ai benefici.<\/p>\n\n<p>Particolarmente importante: implementazione di schemi e applicazioni <strong>orchestrare<\/strong> Mi assicuro che tutti i nodi abbiano una visione coerente prima che si verifichino picchi di carico. Prevenisco gli health check e i readiness probe con brevi finestre di manutenzione e criteri di interruzione chiari. In questo modo la <strong>Disponibilit\u00e0<\/strong> elevato, nonostante la serializzazione DDL globale.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/MariaDB_Schemaaenderungen1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pianificazione nelle configurazioni di hosting<\/h2>\n\n<p>Nelle configurazioni gestite o in cluster, Instant-DDL mostra tutti i suoi punti di forza, perch\u00e9 non devo pi\u00f9 vincolare le implementazioni a lunghe finestre di manutenzione. Soprattutto con lo storage SSD e un elevato livello di parallelismo, riduco gli shock per l'I\/O e <strong>Cache<\/strong>. Coordiner\u00f2 le modifiche con le distribuzioni delle applicazioni, in modo che i feature flag e lo schema vengano attivati in sequenza. Il monitoraggio rimane attivo, ma gli interventi saranno necessari meno spesso. Il risultato sono piani pi\u00f9 chiari e meno attivit\u00e0 operative <strong>I rischi<\/strong>.<\/p>\n\n<p>Prendo inoltre in considerazione gli orari dei backup e i processi batch in esecuzione, in modo che la modifica non cada nel mezzo di report di grandi dimensioni. Negli scenari multi-tenant coordino l\u2019ordine in cui i singoli database vengono elaborati per primi e gli altri seguono. Garantisco la coerenza assicurando l\u2019uniformit\u00e0 nelle configurazioni come ROW_FORMAT. In questo modo evito sorprese qualora in seguito fossero necessarie ulteriori colonne. La pianificazione offre qui un notevole risparmio di tempo <strong>Spese<\/strong>.<\/p>\n\n<h2>Esempi concreti tratti da progetti<\/h2>\n\n<p>Un negozio ha bisogno, con breve preavviso, di un campo relativo a un segmento di clientela per una campagna; aggiungo la colonna tramite INSTANT e il reparto marketing pu\u00f2 inserirvi immediatamente i dati. Una tabella di log registra nuovi parametri tecnici; integro la colonna nel corso della giornata, mentre continuano a svolgersi centinaia di operazioni di scrittura al secondo e l\u2019applicazione <strong>risposte<\/strong>. In un sistema di reporting integro ulteriori campi KPI senza compromettere le chiusure giornaliere. Anche i requisiti normativi possono essere implementati pi\u00f9 rapidamente se i campi di audit vengono inseriti senza necessit\u00e0 di ricostruire il sistema. Queste piccole mosse garantiscono una rapida <strong>Risultati<\/strong>.<\/p>\n\n<p>In tutti i casi, controllo poi le statistiche ed esamino in modo mirato alcuni campioni. Verifico se gli ORM o gli strumenti di migrazione tengano immediatamente conto della colonna. Le cache e gli script di migrazione devono conoscere la nuova struttura, in modo da evitare errori di interpretazione. Per i team pi\u00f9 grandi, documento la modifica in un runbook. In questo modo, la cronologia e le motivazioni alla base delle decisioni rimangono chiare. <strong>comprensibile<\/strong>.<\/p>\n\n<h2>Risoluzione dei problemi quando non \u00e8 immediato<\/h2>\n\n<p>Se un Change si scontra con <code>ALGORITMO=ISTANTANEO<\/code> , cerco innanzitutto i formati incompatibili come <code>ROW_FORMAT=COMPRESSED<\/code> oppure in base a indici specifici. Dopodich\u00e9 controllo i dettagli della versione: nella 10.3 la posizione delle colonne impone di <strong>Fine<\/strong>, a partire dal 10.4 ci sar\u00e0 maggiore flessibilit\u00e0. Se il database restituisce un fallback su INPLACE o COPY, interrompo l'operazione e adatto la strategia o lo schema. Sono significativi <code>MOSTRA AVVISI<\/code> e <code>SHOW CREATE TABLE<\/code> per gli indicatori di layout. Solo quando il caso di test funzioner\u00e0 immediatamente, pianificher\u00f2 la messa in produzione <strong>Esecuzione<\/strong>.<\/p>\n\n<p>Penso anche alle fasi caratterizzate da un elevato carico di transazioni: anche brevi blocchi dei metadati possono causare problemi nei punti critici, se le applicazioni seguono modelli sfavorevoli. Con una pianificazione pi\u00f9 accurata, puntando a una finestra temporale meno trafficata, riesco ad attenuare tali effetti. Inoltre, verifico se trigger, colonne virtuali o chiavi esterne comportino effetti collaterali. Effettuare controlli accurati in anticipo fa risparmiare molto tempo in caso di incidenti. Il mio obiettivo rimane quello di rendere la modifica breve, reversibile e <strong>Trasparente<\/strong> per tenere.<\/p>\n\n<h2>Monitoraggio e risoluzione dei problemi durante il funzionamento<\/h2>\n\n<p>Durante l'implementazione, osservo in modo mirato <strong>MDL<\/strong>-Tempi di attesa e I\/O. <code>INFORMATION_SCHEMA.PROCESSLIST<\/code> e <code>INFORMATION_SCHEMA.METADATA_LOCKS<\/code> mi mostrano se ci sono sessioni in attesa di DDL. Inoltre, utilizzo <strong>performance_schema<\/strong>-Eventi per correlare brevi pause. Sui replicati controllo la latenza del thread SQL e il valore di Seconds_Behind_Master, in modo da poter limitare, se necessario, i backfill o le distribuzioni delle applicazioni. Con l\u2019opzione INSTANT, il binlog cresce solo in misura minima; eventuali valori anomali indicano operazioni nascoste a valle (ad es. la creazione di indici).<\/p>\n\n<p>Dopo la modifica, eseguo la convalida con <code>SPIEGARE<\/code> e le letture campione, per verificare che le query riconoscano correttamente le nuove colonne. Nei dashboard osservo <strong>Threads_running<\/strong>, il contatore degli handler e il tasso di accesso al buffer pool, al fine di individuare eventuali effetti collaterali. Se, nonostante <code>BLOCCO=NESSUNO<\/code> Quando si verificano blocchi, nella maggior parte dei casi \u00e8 presente un hotspot DDL o DML in competizione. In questi casi \u00e8 utile una breve finestra di manutenzione o riprogrammare l'operazione in una fase meno trafficata. Interrompo deliberatamente gli errori, invece di ricorrere a soluzioni di ripiego poco chiare: questo evita lunghe ricostruzioni.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/entwicklerdesk_mariadb_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Confronto tra gli algoritmi DDL<\/h2>\n\n<p>La seguente panoramica classifica COPY, INPLACE e INSTANT e mi aiuta a valutare in modo realistico i rischi e la durata. Valuto inoltre in che misura siano interessati gli accessi simultanei e quali blocchi possano verificarsi. Per una comprensione pi\u00f9 approfondita dei blocchi, vale la pena dare un\u2019occhiata a <a href=\"https:\/\/webhosting.de\/it\/blocco-delle-righe-del-database-mysql-concorrenza-ottimizzazione-prestazioni-blocchi\/\">Blocco a file<\/a> e le ripercussioni sul parallelismo. In questo modo evito decisioni errate in contesti critici per la produzione <strong>Tabelle<\/strong>. La tabella \u00e8 stata volutamente sintetizzata e serve come rapida <strong>Confronto<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Algoritmo<\/th>\n      <th>Serrature<\/th>\n      <th>Copia dei dati<\/th>\n      <th>Durata (tabelle di grandi dimensioni)<\/th>\n      <th>Utilizzo tipico<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>COPY<\/td>\n      <td>pi\u00f9 forte <strong>Serrature<\/strong><\/td>\n      <td>completo<\/td>\n      <td>lungo (fino a ore)<\/td>\n      <td>Modifiche incompatibili, cambio di formato<\/td>\n    <\/tr>\n    <tr>\n      <td>INPLACE<\/td>\n      <td>moderato <strong>Serrature<\/strong><\/td>\n      <td>in parte\/ricco di metadati<\/td>\n      <td>medio (da pochi minuti a pi\u00f9 a lungo)<\/td>\n      <td>numerose modifiche online senza una ricostruzione totale<\/td>\n    <\/tr>\n    <tr>\n      <td>ISTANTANEO<\/td>\n      <td>breve <strong>MDL<\/strong>-fasi<\/td>\n      <td>no (solo metadati)<\/td>\n      <td>molto breve (da ms a s)<\/td>\n      <td>ADD\/DROP COLUMN, cambio di posizione (a partire dalla versione 10.4)<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Interpreto la tabella come un albero decisionale: se INSTANT \u00e8 possibile, lo applico; in caso contrario, valuto INPLACE; solo se entrambe le opzioni falliscono, accetto COPY. La combinazione tra strategia LOCK e algoritmo deve adattarsi al modello di traffico. Soprattutto nel caso di applicazioni con un\u2019elevata attivit\u00e0 di scrittura, mi assicuro in anticipo una via d\u2019uscita. In questo modo, le implementazioni rimangono stabili anche sotto pressione <strong>controllabile<\/strong>. Se lo applico con costanza, risparmio molto <strong>Tempo<\/strong>.<\/p>\n\n<h2>Compatibilit\u00e0 delle applicazioni e ORM<\/h2>\n\n<p>Le modifiche allo schema sono \u201einvisibili\u201c solo se il codice dell\u2019applicazione \u00e8 in grado di gestirle. <strong>SELEZIONARE *<\/strong> e gli accessi posizionali ordinali rappresentano fattori di rischio non appena riorganizzo le colonne (a partire dalla versione 10.4) o inserisco nuovi campi. Preferisco quindi elenchi di colonne espliciti, mappature verificate e la gestione delle versioni dei DTO. Gli ORM e i migration runner spesso memorizzano i metadati nella cache; un riavvio a caldo o un \u201eReprepare\u201c per le istruzioni preparate impedisce interpretazioni errate. Negli ambienti basati su microservizi coordino i rilasci in modo che solo le versioni tolleranti gestiscano il traffico contemporaneamente.<\/p>\n\n<p>Per quanto riguarda la retrocompatibilit\u00e0, valgono le seguenti regole: prima aggiungo la colonna, poi distribuisco il codice che la utilizza in modo opzionale; solo quando tutte le istanze sono state aggiornate e il backfill \u00e8 stato completato, inasprisco i vincoli. In questo modo, i rollforward e i rollback rimangono rapidi e il sistema rimane robusto. Per gli audit, documento la motivazione, l\u2019istruzione SQL, la data, i criteri di successo e la procedura di rollback: ci\u00f2 crea fiducia e garantisce la ripetibilit\u00e0. <strong>Processi<\/strong>.<\/p>\n\n<h2>Scalabilit\u00e0: partizionamento e DDL istantaneo<\/h2>\n\n<p>Il partizionamento e INSTANT si integrano perfettamente, poich\u00e9 le unit\u00e0 fisiche pi\u00f9 piccole rendono gli aggiornamenti ancora pi\u00f9 prevedibili. Quando suddivido le tabelle a livello logico, limito gli hotspot e facilito le successive modifiche. Buono <a href=\"https:\/\/webhosting.de\/it\/strategie-di-partizionamento-dei-database-che-ospitano-database-scalabili\/\">Strategie di partizionamento<\/a> contribuiscono a mantenere gestibili nel lungo periodo set di dati di grandi dimensioni. Nel complesso, ottengo latenze inferiori, finestre di manutenzione pi\u00f9 definite e minori rischi in caso di <strong>Cambiamenti<\/strong>. La nuova colonna sar\u00e0 quindi disponibile pi\u00f9 rapidamente su tutte le partizioni interessate.<\/p>\n\n<p>Pianifico la sequenza: prima la bozza della partizionatura, poi i DDL, infine i backfill per i valori opzionali. In questo modo elimino i conflitti che potrebbero verificarsi in caso di modifiche simultanee agli indici o allo storage. Anche in questo caso, i test rimangono il mio strumento pi\u00f9 potente. Grazie a metriche chiare, riesco a capire se quella fase \u00e8 sostenibile sui sistemi di produzione. Questo approccio disciplinato evita problemi e mantiene il team <strong>concentrato<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-schemawechsel-1832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ripristino dopo un crash, backup e coerenza<\/h2>\n\n<p>INSTANT-DDL modifica solo <strong>Catalogo e metadati<\/strong>. Questo rende l'operazione veloce e atomica. Dopo un crash, la colonna \u00e8 visibile o non lo \u00e8 affatto: non si verifica mai uno \u201estato intermedio\u201c. Il carico sul log di redo\/undo rimane minimo, poich\u00e9 non vengono spostate pagine di dati. Per quanto riguarda la replica: l\u2019evento DDL viene trasmesso in modo pulito; i replichi non devono copiare alcuna riga. I backup fisici in esecuzione durante la modifica dovrebbero catturare la breve modifica dei metadati al momento dello snapshot \u2013 gli strumenti con checkpointing coerente sono in grado di gestirlo. I backup logici includono immediatamente la colonna in <code>CREATE TABLE<\/code>-istruzioni, anche se molte righe riportano ancora il <strong>Predefinito<\/strong> portare.<\/p>\n\n<p>\u00c8 possibile effettuare diverse modifiche istantanee consecutive. Faccio per\u00f2 attenzione a non cambiare posizione o eliminare e ricreare colonne a caso. Modifiche frequenti alla struttura aumentano lo sforzo di coordinamento e, in casi limite, possono portare al punto in cui \u00e8 opportuno procedere a una completa ricostruzione (ad esempio, in caso di necessari cambiamenti di formato). Con una finestra di modifica pragmatica e una roadmap ben definita, tengo sotto controllo il debito tecnico.<\/p>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Con Instant ADD COLUMN posso apportare modifiche allo schema di tabelle di grandi dimensioni in tempo reale, intervenendo solo sui metadati e lasciando inalterati i blocchi di dati. La versione corretta, un ROW_FORMAT compatibile e opzioni DDL chiare come <code>ALGORITMO=ISTANTANEO<\/code> e <code>BLOCCO=NESSUNO<\/code> determinano il successo o la necessit\u00e0 di un rebuild. Per l\u2019operativit\u00e0 e la replica, ci\u00f2 si traduce in un minore lag, implementazioni pianificabili e un elevato <strong>Disponibilit\u00e0<\/strong>. Mi avvalgo di test, monitoraggio e una documentazione accurata per evitare sorprese. In questo modo il mio database rimane flessibile e posso integrare le nuove esigenze senza interruzioni nel <strong>Funzionamento in diretta<\/strong> da.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come MariaDB Instant ADD COLUMN, grazie all'algoritmo INSTANT, consenta di apportare modifiche allo schema senza tempi di inattivit\u00e0 e rivoluzioni la gestione del database con il DDL online di MariaDB.<\/p>","protected":false},"author":1,"featured_media":21224,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21231","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"103","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Instant ADD COLUMN","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21224","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21231"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21224"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}