[MySQL] CHAR vs VARCHAR / 기존에 알던 선택 기준이 흔들리다
기존의 선택기준 - '저장할 데이터가 가변적이면 VARCHAR, 아니면 CHAR'
두 타입은 모두 공통적으로 문자열을 저장하는 용도로 사용되며, 최대 저장 가능 길이를 명시한다는 공통점이 있으나, 뚜렷한 차이를 비교하자면 아래와 같습니다.
| CHAR | VARCHAR |
| 값의 실제 크기와 관계없이 지정된 크기만큼의 저장공간 할당 | 값의 실제 크기만큼의 저장공간 할당 |
따라서, DB를 설계할 때 저장할 데이터의 크기가 고정되어 있다면 CHAR을 선택하고, 가변적이라면 VARCHAR를 선택해왔습니다.
하지만 이는 상황에 따라 맞기도 하고 틀리기도 합니다.
VARCHAR 대신 CHAR를 사용했을 때의 문제점
CHAR는 실제 저장되는 값의 크기가 얼마든, 지정된 크기만큼의 저장공간을 할당하기 때문에 저장되는 데이터의 크기의 편차가 클 경우 공간 낭비가 생길 수 있습니다. 다시 말하자면, 저장되는 데이터의 크기의 편차가 크지 않을 경우 낭비는 크지 않을 것입니다. 여기까지만 보면 무조건적으로 VARCHAR를 사용하는 것이 좋아보입니다.
하지만 VARCHAR를 사용했을 때 오히려 비효율이 발생하는 경우도 있습니다. 이는 바로 VARCHAR 타입의 데이터에 값을 수정 저장하는 방식과 관련이 있는데요.
VARCHAR가 UPDATE 쿼리를 처리하는 방식
먼저 CHAR는 지정된 크기만큼의 저장공간을 할당받습니다. 이에 UPDATE로 데이터 길이에 변화가 생기더라도 최초에 할당받은 메모리 공간을 계속 사용합니다.
하지만 VARCHAR는 다릅니다. 아래 그림을 보겠습니다.
데이터 INSERT 시에 해당 데이터의 크기만큼의 저장공간을 할당받았기에 추후에 그보다 긴 길이의 문자열을 저장하려할 경우 기존의 공간을 활용할 수가 없어집니다. 따라서 기존 공간에 저장되어 있는 데이터는 삭제 처리되고 새로운 공간을 할당받아 데이터를 저장하게 됩니다.
VARCHAR 보다 CHAR를 선택해야 하는 경우
값의 길이 변화의 편차가 작고, 자주 변경되는 경우 CHAR를 선택하는 것이 합리적일 수 있습니다. 이와 같은 경우에 VARCHAR를 사용한다면 데이터의 조각화가 이루어져 빈번한 페이지 재정렬 과정이 요구될 수 있습니다.
결론적으로 단순히 데이터 길이의 가변성만을 기준으로 타입을 정하기보다 그 가변성의 편차를 고려하는 것이 공간 효율에 좋겠습니다.