{"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-instant-add-column-zonder-downtime-schema-update-database","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/mariadb-instant-add-column-ohne-downtime-schemaupdate-datenbank\/","title":{"rendered":"MariaDB Instant ADD COLUMN: schemawijzigingen zonder downtime voor moderne databases"},"content":{"rendered":"<p>MariaDB introduceert met Instant ADD COLUMN een techniek waarmee ik in realtime nieuwe kolommen aan grote InnoDB-tabellen kan toevoegen \u2013 zonder noemenswaardige vergrendelingen en zonder downtime. Het INSTANT-algoritme herschrijft geen gegevens, maar breidt alleen uit <strong>Metagegevens<\/strong> en levert daardoor logisch nieuwe kolommen op met standaardwaarden.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>De volgende kernpunten helpen mij om de mogelijkheden van instant-operaties snel in te schatten en de juiste beslissingen te nemen voor productieve systemen. Ik vat de belangrijkste aspecten samen en breng ze in verband met typische beheertaken. Uit de wisselwerking tussen versie, tabellay-out en DDL-strategie leid ik concrete actiestappen af. De lijst dient als beknopte notitie voor het dagelijkse <strong>Database<\/strong> Beheer. Na het overzicht ga ik dieper in op de implementatie, valkuilen en praktijkvoorbeelden.<\/p>\n\n<ul>\n  <li><strong>Stilstand<\/strong> minimaliseren: nieuwe kolommen in milliseconden zonder rebuild en kopieerprocessen.<\/li>\n  <li><strong>Online DDL<\/strong> veilig besturen: ALGORITHM=INSTANT en LOCK=NONE expliciet opgeven.<\/li>\n  <li><strong>Versie<\/strong> Let op: 10.3 alleen de laatste kolom, vanaf 10.4 flexibele posities en meer.<\/li>\n  <li><strong>Metagegevens<\/strong> in plaats van gegevens: geen fysieke overschrijving, standaardwaarden logisch aanleveren.<\/li>\n  <li><strong>Schalen<\/strong> voordelen: minder replicatievertraging en planbare implementaties.<\/li>\n<\/ul>\n\n<p>De punten komen pas echt tot hun recht als ik compatibiliteitsaspecten zoals ROW_FORMAT of speciale indexen controleer en deze in tests verifieer. Zo houd ik wijzigingen in grote tabellen beheersbaar en blijf ik ook bij piekbelasting <strong>in staat om te handelen<\/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>Waarom Instant ADD COLUMN de spelregels verandert<\/h2>\n\n<p>Vroeger betekende een klassieke <code>ALTER TABLE ... ADD COLUMN<\/code> vaak urenlange kopieerprocessen, blokkerende vergrendelingen en merkbare <strong>Stilstand<\/strong>. Dat paste slecht bij agile releases en 24\/7-toepassingen, waarin elk onderhoudsvenster veel kost. Met het INSTANT-algoritme verschuift de inspanning van het gegevensniveau naar het catalogusniveau, waardoor wijzigingen zelfs bij miljarden regels extreem snel kunnen worden doorgevoerd. Ik kan nieuwe attributen live beschikbaar stellen zonder de lopende belasting te onderbreken. Dat geeft me de ruimte voor snelle iteraties en <strong>Vrijgave<\/strong>-klokfrequentie.<\/p>\n\n<p>Vanuit operationeel oogpunt nemen de risico\u2019s en de co\u00f6rdinatie-inspanningen af, omdat ik geen grote aanpassingen meer hoef te plannen. Deze aanpak heeft direct invloed op replicatie, back-upvensters en de werking van applicaties. Waar vroeger een team nachtelijke interventies co\u00f6rdineerde, volstaat tegenwoordig vaak een korte wijziging met een duidelijk uitrolplan. Hierdoor kan ik productidee\u00ebn sneller testen en in productie nemen. Zo wordt databaseonderhoud een <strong>Hefbomen voor groei<\/strong>.<\/p>\n\n<h2>Zo werkt het INSTANT-algoritme achter de schermen<\/h2>\n\n<p>De kern is simpel: InnoDB breidt de tabellbeschrijving uit en voegt een speciale vermelding toe aan de clusterindex, in plaats van elke rij fysiek te bewerken. Hierdoor bestaan nieuwe kolommen logisch, en bij het lezen levert de engine ofwel de standaardwaarde ofwel een opgeslagen <strong>Waarde<\/strong>. Deze wijziging kost O(1) tijd, afhankelijk van het aantal records, omdat er geen pagina\u2019s opnieuw worden geschreven. Secundaire indexen blijven ongewijzigd, waardoor extra I\/O-werk wordt vermeden. Ik profiteer van de kortst mogelijke locks, minimale I\/O en zeer kleine <strong>Transacties<\/strong>.<\/p>\n\n<p>Zodra ik gegevens in de nieuwe kolom invoer, slaat InnoDB deze waarden zoals gewoonlijk op. Tot dat moment gaat het slechts om een virtuele uitbreiding van de structuur. Juist daarom kunnen veel productieschema\u2019s zonder storingen worden uitgebreid. Ik houd er daarbij rekening mee dat bepaalde combinaties van formaten en functies Instant kunnen verhinderen. Een snelle controle vooraf bespaart me later <strong>Verrassingen<\/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>Versies, formaten en beperkingen<\/h2>\n\n<p>In MariaDB 10.3 kan ik de nieuwe kolom alleen direct aan het einde van de tabel toevoegen; als ik een positie opgeef, wordt de bewerking uitgevoerd met een trager algoritme. Vanaf MariaDB 10.4 maakt een uitgebreid gegevensformaat het mogelijk om op vrijwel elke gewenste plaats kolommen in te voegen, onmiddellijk `DROP COLUMN` uit te voeren en de volgorde van de kolommen te wijzigen. Bepaalde rijformaten zijn hiermee niet compatibel, zoals <code>ROW_FORMAT=COMPRESSED<\/code>, en speciale indexen kunnen beperkingen opleveren. Ik controleer bovendien of <code>innodb_instant_alter_column_allowed<\/code> beperkt het gedrag. Pas als de versie, het formaat en de variabelen kloppen, levert INSTANT mij het verhoopte resultaat <strong>Voordeel<\/strong>.<\/p>\n\n<p>Een snelle realiteitscheck helpt: <code>SELECT VERSION();<\/code>, <code>SHOW CREATE TABLE ...;<\/code> en een droge <code>ALTER TABLE ... ADD COLUMN ... ALGORITHM=INSTANT, LOCK=NONE;<\/code> op de staging-omgeving. Als ik een foutmelding zie, blokkeer ik de wijziging in de productieve omgeving en pas ik het ontwerp of de opties aan. Zo voorkom ik ongewenste rebuilds en de daaruit voortvloeiende piekbelastingen. Vooral bij zeer grote tabellen loont deze voorbereiding de moeite. Ik neem liever een beslissing in de testomgeving dan in <strong>Productiedruk<\/strong>.<\/p>\n\n<h2>Grenzen in detail: gegevenstypen, standaardwaarden en speciale gevallen<\/h2>\n\n<p>Om INSTANT te laten werken, moeten definitie-intervallen aan bepaalde regels voldoen. De volgende vuistregel heeft zijn nut bewezen: <strong>eenvoudige, vaste standaardinstellingen<\/strong> werken, complexe uitdrukkingen vaak niet. Ik zet dus <code>DEFAULT NULL<\/code> of een duidelijke letterlijke waarde (getal, tekenreeks), maar vermijd functieaanroepen zoals <code>NOW()<\/code>, <code>UUID()<\/code> of afhankelijke uitdrukkingen. Voor tekst- en blob-achtige typen gelden, afhankelijk van de versie, aanvullende beperkingen; ik vertrouw niet op mijn intu\u00eftie, maar test met een realistische staging-dump.<\/p>\n\n<p>Niet elk type attribuut leent zich voor een \u201eonmiddellijke\u201c start: een kolom met <code>AUTO_INCREMENT<\/code> invoeren, en meteen ook nog een <strong>Unieke index<\/strong> bouwen of ze direct in een <strong>Vreemde sleutel<\/strong> Als je dit gebruikt, raak je al snel van het instant-pad af. In dergelijke gevallen splits ik de wijziging op in meerdere stappen: eerst de kolom (INSTANT), daarna de index\/constraint (meestal INPLACE). <strong>Gegenereerd<\/strong> of <strong>virtueel<\/strong> Kolommen controleer ik apart; afhankelijk van de uitvoer en de engine worden verschillende algoritmen gebruikt. Tekenset en <strong>Collation<\/strong> Ik leg dit expliciet vast om latere verrassingen bij het sorteren of vergelijken te voorkomen.<\/p>\n\n<p>Ook <strong>Wijzigingen in de positie<\/strong> blijven versieafhankelijk: in 10.3 moet ik kolommen aan het einde plaatsen, vanaf 10.4 heb ik vrijwel de vrije hand. Toch let ik op ORM\u2019s en tools die kolommen op basis van hun ordinale positie adresseren \u2013 daar kan zelfs een verplaatsing zonder het kopi\u00ebren van gegevens logische fouten veroorzaken. Ik plan de positie dus niet alleen technisch, maar houd ook rekening met de applicatiecode.<\/p>\n\n<h2>Best practices: veilige implementatie<\/h2>\n\n<p>Ik formuleer DDL\u2019s altijd expliciet om onduidelijke fallbacks te voorkomen. Met <code>ALGORITME=INSTANT<\/code> en <code>LOCK=NONE<\/code> dwing ik MariaDB om de snelle variant te gebruiken, anders krijg ik een duidelijke foutmelding. Leidt de kolom <code>NOT NULL<\/code>, stel ik een zinvolle standaardwaarde in, zodat oude regels logisch correct zijn <strong>Waarden<\/strong> leveren. V\u00f3\u00f3r de uitrol meet ik op de staging-omgeving de latentie, het replicatiegedrag en de duur van de vergrendeling. Daarnaast leg ik de wijziging nauwkeurig vast in het wijzigingslogboek van de <strong>Database<\/strong>.<\/p>\n\n<p>Handige voorbeelden bieden hulp in de praktijk: <code>ALTER TABLE orders ADD COLUMN marketing_tag VARCHAR(40) DEFAULT '' NOT NULL ALGORITHM=INSTANT, LOCK=NONE;<\/code>. Of voor 10.4+: <code>ALTER TABLE users ADD COLUMN plan INT DEFAULT 0 NOT NULL AFTER status ALGORITHM=INSTANT, LOCK=NONE;<\/code>. In beide gevallen controleer ik vooraf de tabelopties op een compatibel ROW_FORMAT. Tijdens de uitvoering houd ik statistieken zoals Threads_running en I\/O in de gaten. Na de wijziging controleer ik query's die de nieuwe kolom onmiddellijk <strong>gebruik maken van<\/strong>.<\/p>\n\n<h2>Betrouwbare migratiepatronen met backfill en indexen<\/h2>\n\n<p>In productieve omgevingen werk ik met <strong>tweetraps<\/strong> Wijzigingen. Stap 1: voeg de kolom 'instant' toe, om te beginnen <code>NULL<\/code>-compatibel en met een duidelijke standaardinstelling. Stap 2: De applicatie via een feature flag bijwerken, zodat nieuwe schrijfbewerkingen de kolom al vullen, terwijl bestaande gegevens nog leeg zijn. De <strong>Achtervulling<\/strong> ik voer dit asynchroon uit in kleine batches, bijvoorbeeld via een worker die met <code>UPDATE ... WHERE new_col IS NULL ORDER BY pk LIMIT N<\/code> herhaalt en pauzes inlast tussen de runs. Zo blijft de belasting beheersbaar.<\/p>\n\n<p>Als ik een secundaire index op de nieuwe kolom nodig heb, koppel ik deze los van het toevoegen van de kolom. Het aanmaken van de index verloopt meestal <strong>INPLACE<\/strong>, maar duurt evenredig met de hoeveelheid gegevens. Door de ontkoppeling voorkom ik dat de snelle schemawijziging mislukt door langdurige indexbewerkingen. Pas als het backfill-proces is voltooid, voer ik optioneel een <code>NOT NULL<\/code>-stap voor stap \u2013 maar alleen als het algoritme dat toestaat zonder een rebuild. Voor rollbacks volstaat het vaak om de feature-flag terug te zetten en de kolom ongebruikt te laten totdat er een nette terugdraaiing is gepland.<\/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>Prestaties en replicatie<\/h2>\n\n<p>Instant-bewerkingen verminderen de belasting voor de replicaten, omdat er geen omvangrijke kopieerprocessen plaatsvinden. Dit vermindert het risico op merkbare vertraging en ontlast parallel lopende <strong>Query's<\/strong>. In omgevingen met meerdere locaties of cascades speelt dit een cruciale rol voor RTO\/RPO-doelstellingen. Wie geschikte <a href=\"https:\/\/webhosting.de\/nl\/databasereplicatietopologieen-hosting-clusterconfiguratie-schaalbaarheid-database\/\">Replicatietopologie\u00ebn<\/a> kan Changes gericht doorgeven en rollbacks duidelijk structureren. Zo blijft het systeem ook bij pieken in het verkeer <strong>responsief<\/strong>.<\/p>\n\n<p>Ik houd echter rekening met Binlog-formaten en gebeurtenisgroottes om neveneffecten te voorkomen. Bij een zeer hoog schrijfvolume controleer ik de status van de slave en de latentie van de SQL-thread tijdens de wijziging. Wie auditing nodig heeft, kan de DDL-wijziging in de logtagging markeren. Achteraf uitgevoerde ETL-taken moeten tijdig op de hoogte zijn van de nieuwe kolom, zodat nachtelijke runs niet voor niets worden uitgevoerd. Deze co\u00f6rdinatie zorgt voor betrouwbare <strong>Processen<\/strong>.<\/p>\n\n<h2>Bijzonderheden van Galera\/Cluster bij Instant-DDL<\/h2>\n\n<p>In clusters met synchrone replicatie (bijv. Galera) werken DDL-bewerkingen vaak als <strong>TOI<\/strong>-Gebeurtenis (Total Order Isolation). INSTANT verkort de daarvoor benodigde globale co\u00f6rdinatie aanzienlijk, maar er kan toch een korte pauze optreden die het hele cluster betreft. Daarom plan ik dergelijke wijzigingen nog steeds bewust, houd ik sessies kort en vermijd ik gelijktijdige, langlopende transacties die <strong>MDL<\/strong>-de blokkades zouden kunnen verlengen. RSU-strategie\u00ebn (Rolling Schema Upgrade) pas ik alleen doelgericht toe als dat technisch noodzakelijk is \u2013 de operationele overhead is meestal groter dan het voordeel.<\/p>\n\n<p>Bijzonder belangrijk: de uitrol van schema\u2019s en toepassingen <strong>orkestreren<\/strong> Ik zorg ervoor dat alle knooppunten een consistent beeld hebben voordat er pieken in de belasting optreden. Ik voorkom health-checks en readiness-probes door middel van korte onderhoudsvensters en duidelijke criteria voor het afbreken van processen. Zo blijft de <strong>Beschikbaarheid<\/strong> ondanks de wereldwijde DDL-serialisatie hoog.<\/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>Planning bij hostingopstellingen<\/h2>\n\n<p>In managed- of clusteropstellingen komt Instant-DDL goed tot zijn recht, omdat ik implementaties niet langer aan lange onderhoudsvensters hoef te koppelen. Vooral bij SSD-opslag en een hoge mate van parallelliteit verminder ik schokken voor I\/O en <strong>Cache<\/strong>. Ik stem de wijzigingen af op de applicatie-implementaties, zodat feature-flags en het schema in een bepaalde volgorde worden geactiveerd. De monitoring blijft actief, maar ingrijpen is minder vaak nodig. Dit leidt tot duidelijkere plannen en minder operationele <strong>Risico's<\/strong>.<\/p>\n\n<p>Ik houd bovendien rekening met back-upmomenten en lopende batchjobs, zodat de wijziging niet tussen grote rapporten valt. In multi-tenant-scenario\u2019s zorg ik ervoor dat de ene database eerst wordt aangepakt en de andere daarna volgt. Door te zorgen voor uniformiteit bij configuraties zoals ROW_FORMAT waarborg ik consistentie. Zo voorkom ik verrassingen wanneer er later extra kolommen nodig zijn. Planning levert hier een merkbare besparing op. <strong>Uitgaven<\/strong>.<\/p>\n\n<h2>Praktijkgerichte voorbeelden uit projecten<\/h2>\n\n<p>Een winkel heeft voor een campagne op korte termijn een veld voor een klantsegment nodig; ik voeg de kolom via INSTANT toe en de marketingafdeling kan deze direct invullen. Een logtabel registreert nieuwe technische parameters; ik voeg de kolom gedurende de dag toe, terwijl er honderden schrijfbewerkingen per seconde doorgaan en de applicatie <strong>antwoorden<\/strong>. In een rapportagesysteem voeg ik extra KPI-velden toe zonder de dagafsluitingen in gevaar te brengen. Ook kunnen wettelijke vereisten sneller worden ge\u00efmplementeerd als auditvelden zonder een herbouw worden toegevoegd. Deze kleine aanpassingen zorgen voor snelle <strong>Resultaten<\/strong>.<\/p>\n\n<p>In alle gevallen controleer ik daarna de statistieken en bekijk ik gericht steekproeven. Ik controleer of ORM's of migratietools de kolom onmiddellijk in aanmerking nemen. Caches en migratiescripts moeten de nieuwe structuur kennen, zodat er geen verkeerde interpretaties ontstaan. Voor grotere teams documenteer ik de wijziging in een runbook. Zo blijven de geschiedenis en de reden voor de beslissing duidelijk vastgelegd. <strong>begrijpelijk<\/strong>.<\/p>\n\n<h2>Problemen oplossen als het niet meteen lukt<\/h2>\n\n<p>Als een Change botst met <code>ALGORITME=INSTANT<\/code> , zoek ik eerst naar incompatibele formaten zoals <code>ROW_FORMAT=COMPRESSED<\/code> of op basis van speciale indexen. Daarna bekijk ik de versiedetails: in 10.3 dicteert de kolompositie de <strong>Einde<\/strong>, vanaf 10.4 wordt het flexibeler. Als de database een fallback naar INPLACE of COPY geeft, breek ik de bewerking af en pas ik de strategie of het schema aan. Van belang zijn <code>WAARSCHUWINGEN WEERGEVEN<\/code> en <code>SHOW CREATE TABLE<\/code> voor lay-outindicatoren. Pas als het testgeval direct werkt, plan ik de productieve <strong>Uitvoering<\/strong>.<\/p>\n\n<p>Ik houd ook rekening met periodes waarin veel transacties plaatsvinden: zelfs korte metadata-vergrendelingen kunnen in hotspots voor problemen zorgen als applicaties ongunstige patronen vertonen. Door nauwkeuriger te plannen en een rustiger tijdvenster te kiezen, demp ik deze effecten. Daarnaast controleer ik of triggers, virtuele kolommen of externe sleutels neveneffecten hebben. Grondige controles vooraf besparen veel tijd als er zich een incident voordoet. Mijn doel blijft om de wijziging kort, omkeerbaar en <strong>Transparant<\/strong> om vast te houden.<\/p>\n\n<h2>Monitoring en probleemoplossing tijdens het gebruik<\/h2>\n\n<p>Tijdens de uitrol houd ik gericht toezicht <strong>MDL<\/strong>-Wachttijden en I\/O. <code>INFORMATION_SCHEMA.PROCESSLIST<\/code> en <code>INFORMATION_SCHEMA.METADATA_LOCKS<\/code> laten zien of er sessies zijn die wachten op DDL. Daarnaast gebruik ik <strong>performance_schema<\/strong>-Events om korte pauzes te correleren. Op replicaten controleer ik de SQL-thread-latentie en Seconds_Behind_Master, zodat ik indien nodig backfills of app-implementaties kan afremmen. Het binlog groeit bij INSTANT slechts minimaal; uitschieters duiden op verborgen vervolgstappen (bijv. het aanmaken van indexen).<\/p>\n\n<p>Na de wijziging valideer ik met <code>UITLEGGEN<\/code> en sample-reads, zodat query's nieuwe kolommen correct herkennen. In dashboards zie ik <strong>Draden_lopen<\/strong>, handler-teller en bufferpool-hitrate, om neveneffecten op te sporen. Als er ondanks <code>LOCK=NONE<\/code> Als er blokkades optreden, is er meestal sprake van een concurrerende DDL- of DML-hotspot. In dat geval helpt een kort onderhoudsvenster of het verzetten van de taak naar een rustiger moment. Fouten breek ik bewust af, in plaats van in onduidelijke fallbacks terecht te komen \u2013 dat bespaart langdurige rebuilds.<\/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>Vergelijking van de DDL-algoritmen<\/h2>\n\n<p>Het volgende overzicht geeft een overzicht van COPY, INPLACE en INSTANT en helpt mij om de risico\u2019s en de duur realistisch in te schatten. Daarnaast beoordeel ik in hoeverre gelijktijdige toegang hierdoor wordt be\u00efnvloed en welke vergrendelingen kunnen optreden. Voor een beter begrip van vergrendelingen is het de moeite waard om eens te kijken naar <a href=\"https:\/\/webhosting.de\/nl\/database-rijvergrendeling-mysql-concurrency-optimaliseren-prestaties-vergrendelingen\/\">Rijvergrendeling<\/a> en de gevolgen voor de parallelliteit. Zo voorkom ik verkeerde beslissingen bij productiekritieke <strong>Tabellen<\/strong>. De tabel is bewust beknopt gehouden en dient als een snel <strong>Vergelijking<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Algoritme<\/th>\n      <th>Sloten<\/th>\n      <th>Gegevenskopie<\/th>\n      <th>Duur (grote tabellen)<\/th>\n      <th>Typisch gebruik<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>KOPI\u00cbREN<\/td>\n      <td>sterkere <strong>Sloten<\/strong><\/td>\n      <td>volledig<\/td>\n      <td>lang (tot uren)<\/td>\n      <td>onverenigbare wijzigingen, formaatwijzigingen<\/td>\n    <\/tr>\n    <tr>\n      <td>INPLACE<\/td>\n      <td>gematigd <strong>Sloten<\/strong><\/td>\n      <td>gedeeltelijk\/metadata-zwaar<\/td>\n      <td>gemiddeld (enkele minuten tot langer)<\/td>\n      <td>veel online aanpassingen zonder volledige heropbouw<\/td>\n    <\/tr>\n    <tr>\n      <td>INSTANT<\/td>\n      <td>kort <strong>MDL<\/strong>-fasen<\/td>\n      <td>nee (alleen metadata)<\/td>\n      <td>heel kort (ms tot s)<\/td>\n      <td>ADD\/DROP COLUMN, wijziging van positie (vanaf 10.4)<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Ik interpreteer de tabel als een beslissingsboom: als INSTANT mogelijk is, geef ik daar de voorkeur aan; zo niet, dan bekijk ik INPLACE; alleen als beide mislukken, accepteer ik COPY. De combinatie van LOCK-strategie en algoritme moet aansluiten bij het verkeerspatroon. Vooral bij toepassingen met veel schrijfverkeer zorg ik van tevoren voor een uitweg. Zo blijven implementaties ook onder druk <strong>bestuurbaar<\/strong>. Als ik dit consequent toepas, bespaar ik veel <strong>Tijd<\/strong>.<\/p>\n\n<h2>Compatibiliteit van applicaties en ORM's<\/h2>\n\n<p>Wijzigingen in het schema zijn alleen \u201eonzichtbaar\u201c als de applicatiecode deze aankan. <strong>SELECT *<\/strong> en toegang via ordinal-posities vormen risicofactoren zodra ik kolommen herschik (vanaf 10.4) of nieuwe velden invoeg. Ik geef daarom de voorkeur aan expliciete kolomlijsten, gecontroleerde mappings en versiebeheer van DTO\u2019s. ORM\u2019s en migratierunners slaan vaak metadata op in de cache; een \u201ewarm\u201c herstart of een \u2018Reprepare\u2019 voor voorbereide statements voorkomt verkeerde interpretaties. In microservice-omgevingen co\u00f6rdineer ik releases zodanig dat alleen compatibele versies tegelijkertijd verkeer verwerken.<\/p>\n\n<p>Wat achterwaartse compatibiliteit betreft, geldt het volgende: eerst de kolom toevoegen, daarna de code uitrollen die er optioneel gebruik van maakt; pas als alle instanties zijn bijgewerkt en de backfill is voltooid, verscherp ik de constraints. Zo blijven de- en rollforwards vlot verlopen en blijft het systeem robuust. Voor audits documenteer ik de motivering, de SQL-instructie, het tijdstip, de succescriteria en de terugkeerprocedure \u2013 dat schept vertrouwen en zorgt voor herhaalbare <strong>Processen<\/strong>.<\/p>\n\n<h2>Schaalbaarheid: partitionering en Instant-DDL<\/h2>\n\n<p>Partitionering en INSTANT vullen elkaar uitstekend aan, omdat kleinere fysieke eenheden updates nog beter voorspelbaar maken. Door tabellen logisch op te splitsen, beperk ik hotspots en maak ik latere aanpassingen eenvoudiger. Goed <a href=\"https:\/\/webhosting.de\/nl\/database-partitioneringsstrategieen-hosting-schaalbare-databases\/\">Partitioneringsstrategie\u00ebn<\/a> helpen om zeer grote datasets op lange termijn beheersbaar te houden. Al met al zorg ik voor lagere latentie, duidelijkere onderhoudsvensters en minder risico bij <strong>Veranderingen<\/strong>. De nieuwe kolom is dan sneller beschikbaar op alle relevante partities.<\/p>\n\n<p>Ik plan de volgorde als volgt: eerst het ontwerp van de partitie-indeling, dan de DDL\u2019s, en vervolgens de backfills voor optionele waarden. Zo voorkom ik conflicten die zouden kunnen ontstaan bij gelijktijdige aanpassingen aan indexen of opslagruimten. Ook hier blijft testen mijn krachtigste hulpmiddel. Aan de hand van duidelijke statistieken kan ik vaststellen of de stap op de productiesystemen haalbaar is. Deze gedisciplineerde aanpak bespaart gedoe en houdt het team <strong>geconcentreerd<\/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>Crash-Recovery, back-ups en consistentie<\/h2>\n\n<p>INSTANT-DDL wijzigt alleen <strong>Catalogus- en metagegevens<\/strong>. Dat maakt de bewerking snel \u2013 en atomair. Na een crash is de kolom \u00f3f zichtbaar \u00f3f helemaal niet; er ontstaat geen \u201etussenliggende toestand\u201c. De belasting van het redo\/undo-log blijft minimaal, omdat er geen gegevenspagina\u2019s worden verplaatst. Voor replicatie geldt: de DDL-gebeurtenis wordt netjes doorgegeven; replicaten hoeven geen rijen te kopi\u00ebren. Fysieke back-ups die tijdens de wijziging lopen, moeten de korte metagegevenswijziging op het moment van de snapshot vastleggen \u2013 tools met consistente checkpoints kunnen dit aan. Logische back-ups nemen de kolom onmiddellijk op in <code>CREATE TABLE<\/code>-instructies, ook al bevatten veel regels nog steeds de <strong>Standaard<\/strong> dragen.<\/p>\n\n<p>Er zijn meerdere opeenvolgende onmiddellijke wijzigingen mogelijk. Ik let er echter op dat ik niet zomaar vaak van positie wissel of kolommen verwijder en weer aanmaak. Frequente structuurwijzigingen verhogen de co\u00f6rdinatie-inspanning en kunnen in uitzonderlijke gevallen ertoe leiden dat het op een gegeven moment zinvol is om de structuur volledig opnieuw op te bouwen (bijvoorbeeld bij noodzakelijke formaatwijzigingen). Met een pragmatisch wijzigingsvenster en een overzichtelijke roadmap houd ik technische schulden binnen de perken.<\/p>\n\n<h2>Kort samengevat<\/h2>\n\n<p>Met Instant ADD COLUMN voer ik schemawijzigingen in grote tabellen in realtime door, waarbij ik alleen de metagegevens aanpas en de gegevensblokken ongewijzigd laat. De juiste versie, een compatibel ROW_FORMAT en duidelijke DDL-opties zoals <code>ALGORITME=INSTANT<\/code> en <code>LOCK=NONE<\/code> bepalen of het een succes wordt of dat er een herstart nodig is. Voor de bedrijfsvoering en replicatie betekent dit minder vertraging, voorspelbare implementaties en hoge <strong>Beschikbaarheid<\/strong>. Ik maak gebruik van tests, monitoring en een gedegen documentatie om verrassingen te voorkomen. Zo blijft mijn database flexibel en kan ik nieuwe vereisten zonder onderbreking in de <strong>Live werking<\/strong> van.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe MariaDB Instant ADD COLUMN dankzij het INSTANT-algoritme schemawijzigingen mogelijk maakt zonder downtime en een revolutie teweegbrengt in het databasebeheer met mariadb online DDL.<\/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":"107","_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\/nl\/wp-json\/wp\/v2\/posts\/21231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21231"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21231\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21224"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}