Antwort.

Hintergrund der Frage

Die Änderung des Schemas einer Tabelle wurde mit der weit verbreiteten Nutzung von Agile-Methoden relevant. Projekte entwickeln sich weiter, Anforderungen ändern sich – im Laufe der Zeit entsteht zwangsläufig die Notwendigkeit, Spalten hinzuzufügen, zu ändern oder zu entfernen. Solche Änderungen sind in produktiven Datenbanken besonders riskant.

Problem

Die Modifikation der Struktur kann führen zu:

langen Sperren
Verlust oder inkorrekter Migration alter Daten
Verletzung externer Einschränkungen, Trigger oder Logik der Anwendung

Besonders schwierig sind Änderungen an großen Tabellen (Millionen von Zeilen), die von anderen Diensten aktiv genutzt werden.

Lösung

Eine durchdachte Arbeit über ALTER TABLE – schrittweise Änderungen, Erstellung von Datensicherungen, Tests auf einer Testumgebung, Begrenzung der Ausfallzeiten. Verwendung von Transaktionen, schrittweise Migration und Backup vor größeren Änderungen. In stark belasteten DBMS werden häufig "online"-Algorithmen für ALTER verwendet.

Beispielcode:

-- Hinzufügen einer neuen Spalte mit Standardwert
ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'new';

-- Schrittweise Befüllung der neuen Spalten
UPDATE orders SET status = CASE WHEN shipped_at IS NOT NULL THEN 'shipped' ELSE 'pending' END;

Hauptmerkmale:

Es ist ratsam, zunächst neue Spalten zu erstellen und dann schrittweise Daten zu übertragen
Große Operationen außerhalb der Hauptlastzeiten durchführen
Immer ein Backup und automatische Tests durchführen

Fangfragen.

Wird ALTER TABLE atomar ausgeführt?

In der Regel nein: Die Änderung einer Tabelle kann viel Zeit in Anspruch nehmen. Bei einem Fehler kann ein Teil der Änderungen zurückgerollt werden, während der andere Teil hängen bleibt. Daher wird der transaktionale Schutz für DDL-Befehle nur von einigen DBMS (z.B. PostgreSQL) umgesetzt.

Kann man den Typ einer Spalte von INTEGER auf VARCHAR schmerzfrei ändern?

Nicht immer: Wenn in der Spalte alte Daten vorhanden sind, die nicht dem neuen Format entsprechen, oder wenn verbundene Objekte (Indizes, Trigger, Schlüssel) vorhanden sind, kann das DBMS die Änderung des Typs verweigern oder die Daten werden beschädigt.

Legt ALTER TABLE immer eine exklusive Sperre auf die gesamte Tabelle?

Hängt vom DBMS ab: In MySQL und älteren Versionen von SQL Server blockiert jede ALTER-Operation häufig die gesamte Tabelle bis zum Abschluss, aber moderne DBMS unterstützen "online DDL", wodurch die Sperrzeit verringert wird.

Typische Fehler und Anti-Pattern

Strukturänderungen ohne Backup
Migration großer Tabellen ohne Test auf einer Staging-Umgebung
Umbenennung von Spalten ohne Überprüfung der Abhängigkeiten (z.B. externe Schlüssel, Prozeduren)
Massives ALTER zu Stoßzeiten

Beispiel aus der Praxis

Negativer Fall

Ein DevOps-Ingenieur nahm massive Änderungen an drei wichtigen Tabellen über ALTER TABLE vor und löschte alte Spalten. Er berücksichtigte nicht, dass diese Spalten mit externen Schlüsseln und Triggern verknüpft waren. Während der Ausführung von ALTER war die Datenbank 20 Minuten beschäftigt – in dieser Zeit fielen die Dienste aufgrund fehlender benötigter Felder aus.

Vorteile:

Die Änderungen wurden gemäß den Anforderungen umgesetzt

Nachteile:

Verlust der Betriebsfähigkeit eines Teils der Dienste
Ausfall des Geschäfts für fast eine halbe Stunde
Aufwendige Wiederherstellung der Abhängigkeiten und Rückführung der gelöschten Daten

Positiver Fall

Ein Analyst plante die Hinzufügung einer Spalte in mehreren Schritten: Zunächst wurde eine Spalte mit einem Standardwert erstellt, dann wurde eine Testlast auf Kopien aufgebracht, erst danach wurde das tatsächliche ALTER nachts durchgeführt und alle Entwickler über das bevorstehende Migrationsfenster informiert.