CHAR / VARCHAR

문자열을 사용할 때 VARCHAR만 사용하는 경우도 있지만, 모든 DBMS에서 두 타입으로 구분해서 제공하는 만큼 각각의 특징을 잘 이해하고 사용하는 것이 중요하다.

저장 공간

CHAR와 VARCHAR의 가장 큰 차이는 고정 길이냐 가변 길이냐의 차이이다.

• 고정 길이(CHAR): 실제 입력되는 컬럼값의 길이에 따라 사용하는 저장 공간의 크기가 변하지 않음

• 가변 길이(VARCHAR): 최대로 저장할 수 있는 길이가 제한되어 있지만, 그 이하 크기 값이 저장되면 그 만큼만 저장 공간을 사용(+ 추가적으로 유효 크기를 저장하기 위한 1~2바이트 공간이 필요)

이렇게 보면 1바이트의 차이만 나기 때문에 항상 VARCHAR를 사용하는 것이 좋을 것 같지만, 아래 두 가지 판단 기준으로 CHAR를 사용하는 것이 더 효율적일 수 있다.

• 저장되는 문자열의 길이가 대부분 비슷한 경우

• 컬럼의 값이 자주 갱신되는 경우

가변 길이의 VARCHAR의 경우 저장되는 문자열의 길이가 달라지는 경우 디스크에 할당된 공간을 재할당하고, 이전에 사용했던 공간을 해제하는 디스크에 대한 I/O 작업을 하기 때문에 성능에 영향을 미친다. 하지만 고정 길이의 CHAR의 경우 저장되는 문자열의 길이가 달라지더라도 레코드가 물리적으로 저장되는 위치가 변하지 않기 때문에 디스크 I/O 작업이 필요하지 않다.

VARCHAR 추가 저장 공간

위에서 VARCHAR는 유효 크기 저장을 위한 1~2바이트 공간이 추가로 필요하다고 했는데, 이는 공간의 사용 크기가 255바이트 이하일 경우 1바이트, 255바이트 초과일 경우 2바이트가 필요하기 때문이다. VARCHAR의 최대 길이는 2바이트로 표현할 수 있는 이상은 사용할 수 없기 때문에 65,536 바이트 이상으로 지정할 수 없다.

VARCHAR 저장 공간 변경 DDL

VARCHAR의 저장 공간을 변경하는 경우 작업에 따라 매우 빠르게 처리되기도 하지만, 특수한 경우에는 읽기 잠금을 걸고 레코드 복사 작업이 필요하기 때문에 시간이 오래 걸릴 수 있다.

VARCHAR(60) 컬럼을 VARCHAR(63)으로 변경하는 경우와 VARCHAR(64)로 변경하는 경우를 비교해보자.

• VARCHAR(63)으로 변경하는 경우

  • INPLACE 알고리즘으로 처리되어 잠금 없이 매우 빠르게 처리

• VARCHAR(64)로 변경하는 경우

  • COPY 알고리즘으로 처리되어 읽기 잠금을 걸고 레코드 복사 작업이 필요하기 때문에 시간이 오래 걸림

  • 64 크기로 변경하게 되면서 컬럼의 최대 길이가 256(64 * 4)바이트가 되기 때문에 1바이트에서 2바이트로 유효 크기 저장 공간 크기 변경 필요

  • 문자열 길이를 저장하는 공간의 크기가 바뀌게 되면 MySQL 서버에서 읽기 잠금을 걸어 레코드를 복사하는 작업이 필요하다.

위와 같은 이유 때문에 VARCHAR의 크기는 초기 설계 단계에서 저장 공간의 크기가 변경되지 않도록 미리 크게 설계하는 것이 좋다.

참고자료

• Real MySQL 8.0 (2권)