✍️ Today I Learned

MariaDB(MySQL)에서 ALTER TABLE 명령어를 사용하여 ENUM 타입의 필드를 수정하는 작업은 테이블 전체를 재구성하여 오래 걸리는 작업으로 알고 있었다. 특히 데이터가 많은 운영 환경의 테이블일수록 부담이 커, 해당 작업은 기피 대상 중 하나였다.

하지만 모든 ENUM 수정 작업이 동일한 비용을 발생시키는 것은 아니었다.

ENUM 목록의 가장 마지막에 새로운 요소를 추가하는 작업은 테이블의 메타데이터만 변경하므로 기존에 알던 것과 달리 매우 빠른 속도로 완료되었다. 반면, ENUM 목록의 중간에 값을 삽입하거나 기존 값을 변경하는 작업은 테이블 전체를 다시 쓰는 과정을 거치므로 테이블 크기에 비례하여 많은 시간이 소요되는 것이 맞았다.

이번 포스팅에서는 ENUM 타입의 내부 동작 원리를 통해 왜 이러한 성능 차이가 발생하는지에 대한 학습 내용을 기록으로 남긴다.

1. ENUM의 내부 저장 구조와 동작 원리

ENUM 타입의 ALTER 성능 차이를 이해하려면, 먼저 ENUM이 데이터베이스 내부에 어떻게 저장되는지 알아야 했다.

결론부터 말하자면, ENUM은 우리가 정의한 문자열 그대로 저장되지 않는다. 대신, 각 문자열 값은 내부적으로 정수 인덱스(integer index)에 1:1로 매핑되어 저장된다.

예를 들어, ENUM('APPLE', 'BANANA', 'ORANGE')와 같이 컬럼을 선언했다면, 실제 데이터는 아래와 같이 정수로 변환되어 관리된다.

'APPLE'은 정수 1에 매핑된다.
'BANANA'는 정수 2에 매핑된다.
'ORANGE'는 정수 3에 매핑된다.

만약 테이블에 'BANANA'라는 값을 가진 행을 삽입하면, 문자열 'BANANA'가 아닌 정수 2가 기록되는 방식이다.

이러한 내부 동작 방식은 저장 공간을 절약하고, 특정 상황에서 문자열 비교보다 빠른 정수 비교를 통해 성능적 이점을 얻게된다. 하지만, 이러한 인덱스 기반의 저장 구조가 ALTER TABLE 명령을 실행할 때 성능 차이를 만들어내는 핵심 원인이었다.

2. 빠른 ALTER: ENUM 목록 끝에 값 추가

그렇다면 ENUM 목록의 가장 마지막에 새로운 값을 추가하는 ALTER TABLE 쿼리는 왜 빨랐을까?

ALTER TABLE my_table MODIFY COLUMN my_column ENUM('APPLE', 'BANANA', 'ORANGE', 'GRAPE');

위와 같이 기존 목록 ('APPLE', 'BANANA', 'ORANGE')의 끝에 'GRAPE'를 추가하는 경우를 가정해 보면, 데이터베이스의 내부 동작은 매우 효율적이었다.

기존의 인덱스 매핑(APPLE = 1, BANANA = 2, ORANGE = 3)은 전혀 변경되지 않는다.
새롭게 추가된 'GRAPE'에 다음 순번인 정수 인덱스 4가 새롭게 할당된다.

가장 중요한 점은, 테이블에 이미 저장되어 있던 기존 데이터(1, 2, 3)를 전혀 수정할 필요가 없다는 것이었다. 작업은 테이블의 구조 정보, 즉 메타데이터를 변경하는 선에서 마무리된다. 이는 테이블의 실제 데이터를 한 줄도 읽거나 쓰지 않는 작업이므로, 테이블의 전체 크기와 무관하게 작업이 거의 즉시 완료되는 결과를 낳았다.

🤔 Understanding

이번 학습을 통해 ENUM 타입에 대해 다시 한번 정리할 수 있었다.

먼저 ENUM을 사용함으로써 얻는 이점은 명확하다.

데이터 무결성 보장: 정의된 값만 저장할 수 있으므로, 오타나 잘못된 데이터가 입력될 가능성을 원천적으로 차단한다.
저장 공간 효율성: 문자열이 아닌 내부 정수 인덱스로 데이터를 관리하므로, 저장 공간을 절약할 수 있다.
가독성 향상: status = 1과 같은 코드보다 status = 'COMPLETED'와 같이 직관적인 코드를 가능하게 하여 가독성을 높인다.

하지만 이러한 장점에도 불구하고, ENUM을 수정할 때는 반드시 기억해야 할 주의사항이 있었다.

새로운 값은 반드시 목록의 가장 마지막에 추가해야 한다.
- 이는 테이블의 실제 데이터를 변경하지 않고 메타데이터만 수정하는 빠른 작업이다.
목록의 중간에 값을 추가하거나 순서를 변경하는 ALTER TABLE 쿼리는 되도록 피해야 한다.
- 이 작업은 테이블 전체를 재구성하는 과정(Table Rebuild)을 유발하며, 대용량 테이블에서는 서비스 장애의 원인이 될 수 있다.
불가피하게 중간을 수정해야 한다면, 서비스 점검 시간을 확보하거나 별도의 툴을 이용한 계획이 반드시 필요하다.

결론적으로 ENUM은 데이터의 일관성과 명확성을 보장해 주는 매우 유용한 기능임이 틀림없었다. 하지만 그 내부 동작 방식을 제대로 이해하지 못하고 사용할 경우, 예상치 못한 성능 저하와 장애를 마주할 수 있는 양날의 검과 같았다.

이번 기회를 통해 ENUM의 내부 동작 원리를 이해하고 올바르게 사용하는 것이 무엇보다 중요함을 다시 한번 확인할 수 있었다.