Usunięcie kolumny rzadko zaczyna się od DDL. Zaczyna się od incydentu na produkcji, zalegającego zgłoszenia migracji albo alertu o schema drift, który pokazuje, że jedna usługa wciąż zapisuje dane do pola uznawanego przez wszystkich za martwe.

Dlatego „jak usuwać kolumny” to w rzeczywistości problem migracji etapowej. Instrukcja ALTER TABLE ... DROP COLUMN jest ostatnim krokiem, a nie pierwszym. Zespoły wpadają w kłopoty, gdy traktują usunięcie kolumny jak sprzątanie, a nie jak zmianę zgodności, która może zepsuć odczyty, zapisy, zadania ETL, modele BI, eksporty i ścieżki rollbacku.

Bezpieczny proces usuwania składa się z siedmiu części:

1. Potwierdź, że kolumna nie jest używana
   Sprawdź kod aplikacji, modele ORM, procedury składowane, widoki, zaplanowane zadania, dashboardy, pipeline’y CDC i doraźne zapytania analityków. Użycie często przetrwa w jednym zapomnianym raporcie lub procesie działającym w tle.

2. Sprawdź sygnały schema drift, zanim dotkniesz produkcji
   Drift to poważny sygnał ostrzegawczy. Jeśli środowiska różnią się co do obecności kolumny, dopuszczalności wartości NULL, wartości domyślnych lub oczekiwań systemów zależnych, usunięcie kolumny pogłębi tę rozbieżność i utrudni diagnozę awarii.

3. Najpierw oznacz jako przestarzałą, potem usuń
   Oznacz kolumnę jako przestarzałą w dokumentacji schematu i notatkach migracyjnych. Najpierw zatrzymaj nowe zapisy. W wielu systemach utrzymanie odczytów przez jeden cykl wydania pozwala uniknąć niepotrzebnych awarii.

4. Najpierw wdróż zmiany w aplikacji
   Usuń zapisy, potem odczyty, a następnie wdróż. Jeśli aplikacja nadal odwołuje się do kolumny po wykonaniu DDL, awaria jest na własne życzenie.

5. Zrób kopię zapasową i przetestuj rollback
   Usunięcie kolumny jest proste. Przywrócenie jej z właściwym typem, ograniczeniami, wartościami domyślnymi i danymi historycznymi to moment, w którym odtwarzanie się komplikuje. Przetestuj ścieżkę rollbacku przed wykonaniem właściwej zmiany.

6. Usuń kolumnę w kontrolowanym oknie czasowym
   Nawet proste DDL może zablokować tabele, unieważnić plany wykonania lub spowodować opóźnienie replikacji, w zależności od silnika bazy danych i rozmiaru tabeli. Zachowanie na produkcji liczy się bardziej niż podręcznikowa składnia.

7. Monitoruj drift i awarie zależności po zmianie
   Obserwuj narzędzia do porównywania schematów, logi błędów, przebiegi ETL i odświeżanie dashboardów. Jeśli coś nadal oczekuje starej kolumny, drift po zmianie i błędy wykonania szybko to ujawnią.

Składnia to łatwa część. Trudniej jest udowodnić, że usunięcie kolumny nie spowoduje cichej niezgodności między schematem, który zamierzałeś mieć, a tym, którego istnienie wciąż zakładają Twoje systemy.

Wykrywanie driftu przed usunięciem kolumny i po nim jest łatwiejsze, gdy zmiany schematu są śledzone automatycznie, a nie porównywane ręcznie. Aby zobaczyć, jak dodane, usunięte i zmienione co do typu kolumny pojawiają się w każdej monitorowanej tabeli, zajrzyj do digna Schema Tracker.

Najczęściej zadawane pytania

Czy bezpiecznie jest uruchomić ALTER TABLE DROP COLUMN bezpośrednio na produkcji?

Tylko po wykonaniu prac przygotowawczych. Instrukcja DROP COLUMN powinna być ostatnim krokiem migracji etapowej, po potwierdzeniu, że kolumna nie jest używana, zatrzymaniu zapisów, usunięciu odczytów z aplikacji i przetestowaniu rollbacku. Uruchomienie jej na początku zamienia sprzątanie w awarię.

Jak sprawdzić, czy kolumna jest nadal używana?

Przeszukaj wszystkie miejsca, w których kolumna może się ukrywać: kod aplikacji, modele ORM, procedury składowane, widoki, zaplanowane zadania, dashboardy, pipeline’y CDC i doraźne zapytania analityków. Ostatnim odbiorcą bywa zapomniany raport lub proces w tle, dlatego oprócz kodu warto przejrzeć logi zapytań.

Dlaczego schema drift ma znaczenie przed usunięciem kolumny?

Jeśli środowiska już różnią się co do obecności kolumny, dopuszczalności NULL lub wartości domyślnych, jej usunięcie pogłębia tę rozbieżność i znacznie utrudnia diagnozę wynikającej z tego awarii. Traktuj drift jako sygnał ostrzegawczy i uzgodnij środowiska przed zmianą produkcji, a nie dopiero po awarii.

W jakiej kolejności wprowadzać zmiany w aplikacji i usuwać kolumnę?

Najpierw zatrzymaj nowe zapisy, następnie usuń odczyty, wdróż te zmiany w aplikacji i dopiero wtedy uruchom DDL. Utrzymanie odczytów przez jeden cykl wydania pozwala uniknąć niepotrzebnych awarii. Jeśli aplikacja nadal odwołuje się do kolumny w chwili jej zniknięcia, awaria jest w pełni na własne życzenie.

Co monitorować po usunięciu kolumny?

Obserwuj narzędzia do porównywania schematów, logi błędów, przebiegi ETL i odświeżanie dashboardów. Wszystko, co nadal oczekuje starej kolumny, szybko zakończy się błędem wykonania albo driftem po zmianie, dlatego krótkie, ukierunkowane monitorowanie zaraz po usunięciu wychwytuje większość pozostałych zależności.