답변.

문제의 역사

테이블 스키마 변경은 애자일 방법론의 확산과 함께 중요해졌습니다. 프로젝트는 진화하고 요구 사항이 바뀌며 시간이 지남에 따라 열을 추가/변경/삭제할 필요성이 반드시 생깁니다. 운영 생산 데이터베이스에서 이러한 변경은 특히 위험합니다.

문제점

구조 수정은 다음과 같은 문제를 야기할 수 있습니다:

장기적인 잠금
기존 데이터의 손실 또는 잘못된 마이그레이션
외부 제약 조건, 트리거 또는 애플리케이션 로직의 위반

대규모 테이블(수백만 행)에서의 변경은 특히 복잡하며, 다른 서비스에서 적극적으로 사용되고 있습니다.

해결책

ALTER TABLE을 통해 신중하게 작업하는 것이 중요합니다 — 단계적 변경, 데이터 복사본 작성, 스탠드에서 테스트, 다운타임 시간 제한. 트랜잭션 사용, 단계적 마이그레이션 및 대규모 변경 전 백업 수행. 고부하 데이터베이스에서는 "온라인" ALTER 알고리즘을 자주 사용합니다.

코드 예시:

-- 기본값이 있는 새 열 추가
ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'new';

-- 새 열에 대한 점진적 데이터 채우기
UPDATE orders SET status = CASE WHEN shipped_at IS NOT NULL THEN 'shipped' ELSE 'pending' END;

주요 특징:

먼저 새 열을 만들고, 그런 다음 데이터를 점진적으로 이동하는 것이 바람직합니다.
대규모 작업은 피크 시간이 아닌 시간에 수행하십시오.
항상 백업 및 자동 테스트 수행

기만적인 질문.

ALTER TABLE은 원자적으로 실행되나요?

대부분의 경우 그렇지 않습니다. 테이블 변경에는 오랜 시간이 걸릴 수 있습니다. 오류가 발생하면 일부 변경 사항은 롤백될 수 있지만 일부는 영구적으로 남을 수 있습니다. 따라서 DDL 명령에 대한 트랜잭션 보호를 구현하는 데이터베이스 관리 시스템은 일부(DBMS)에서만 지원합니다(예: PostgreSQL).

INTEGER 형식을 VARCHAR로 변경하는 것이 무통증에서 가능한가요?

항상 그렇지는 않습니다. 새 형식과 일치하지 않는 오래된 데이터가 열에 있거나 관련된 객체(인덱스, 트리거, 키)가 존재하는 경우, DBMS는 형식을 변경하지 않거나 데이터가 손상될 수 있습니다.

ALTER TABLE은 항상 테이블 전체에 독점 잠금을 걸까요?

DBMS에 따라 다릅니다. MySQL 및 이전 버전의 SQL Server에서는 ALTER 작업이 종종 테이블을 완전히 잠그게 됩니다. 그러나 현대 DBMS는 "온라인 DDL"을 지원하여 잠금 시간을 줄입니다.

일반적인 실수 및 반패턴

백업 없이 구조 변경
스탠드에서 테스트 없이 대규모 테이블 마이그레이션
의존성 확인 없이 열 이름 변경(예: 외부 키, 프로시저)
피크 시간대에 대규모 ALTER 수행

실생활 예시

부정적인 사례

DevOps 엔지니어는 ALTER TABLE을 통해 세 개의 중요한 테이블에 대규모 변경 사항을 적용하고 오래된 열을 삭제했습니다. 이 열에 외부 키와 트리거가 연결되어 있음을 간과했습니다. ALTER 작업 중에 데이터베이스가 20분간 중단되었고 이로 인해 서비스가 "중단"되었습니다.

장점:

변경 사항이 기술 요구 사항에 따라 이루어졌습니다.

단점:

일부 서비스의 기능 상실
비즈니스 중단이 거의 30분간 지속
의존성을 복구하고 삭제된 데이터를 복원하는 데 소모되는 시간

긍정적인 사례

분석가는 여러 단계에 걸쳐 열 추가를 계획했습니다. 먼저 기본값으로 열을 생성하고 테스트 부하를 복사본에 채운 다음 실제 ALTER를 밤에 수행하고 모든 개발자에게 예정된 마이그레이션 창에 대해 알렸습니다.