[MySQL] CHAR VARCHAR

데이터 타입

컬럼의 데이터 타입과 길이를 선정할 때 주의해야 할 사항

● 저장되는 값의 성격에 맞는 최적의 타입 선정

● 가변 길이 컬럼은 최적의 길이를 지정

● 조인 조건으로 사용되는 컬럼은 똑같은 데이터 타입으로 선정

​

컬럼의 데이터 타입을 선정할 때 저장되는 값의 특성을 고려하지 않고 가능한 길이 값을 기준으로 컬럼의 길이를 선택하는게 일반적.

BUT!

무분별한 컬럼의 길이가 크게 선정이 된다면 디스크의 공간은 물론 메모리, CPU의 자원도 함께 낭비를 하게된다.

이로인해 SQL의 성능 저하가 발생

​

CHAR(n) , VARCHAR(n) <괄호 안 n 의 값은 문자 수를 의미함>

​

CHAR , VARCHAR

두 문자열 데이터의 공통점은 문자열 데이터 타입 이라는 것이다.

가장 큰 차이는 고정길이냐 가변 길이냐의 여부이다.

​

▶고정길이(CHAR) : 선언된 길이에 관계없이 고정된 크기로 저장을 한다.

→CHAR(10)으로 선언된 경우엔 , 저장된 문자열이 "ABC"라면, 나머지 공간( 7bite)는 공백으로 채워진다.

​

▶가변길이(VARCHAR) : 실제 데이터의 길이에 따라 필요한 만큼 저장을 한다.

→VARCHAR(10)으로 선언된 경우 , "ABC" 저장하면 3바이트만 사용된다.

▶추가 오버헤드 : 데이터 길이를 저장하기 위해 1~2 바이트의 추가 공간이 필요하다.

​

하나의 글자를 저장하기 위해 CHAR(1), VARCHAR(1) 타입을 사용할 때 실제 사용되는 저장 공간의 크기를 한번 보자면

●CHAR (1)

▶고정 길이 타입 : 항상 1바이트를 차지

▶MySQL의 CHAR타입은 고정 길이로 저장되기 때문에, 1 문자를 저장하는데 1 바이트가 사용 됨.

→ UTF-8 인코딩에서는 기본적으로 1~4 바이트가 필요한데, 한 글자가 1 바이트가 아닐 수도 있슴.

​

●VARCHAR (1)

▶MySQL에서 길이를 기록하기 위해 1~2 바이트를 사용.

▶VARCHAR(1)에서는 최대 데이터 길이가 1이므로, 추가로 1바이트의 길이 정보가 필요로 함.

→ VARCHAR(1)은 최소 2 바이트 (1 바이트 데이터 + 1바이트 길이 정보)가 사용이 됨.

→ "A"를 저장한다면 1바이트는 데이터, 1바이트는 길이 정보 사용 = 2 바이트

데이터 타입	실제 저장 공간	추가 설명
CHAR(1)	1바이트	고정 길이, 단순 구조
VARCHAR(1)	2바이트	1 바이트 데이터 + 1바이트 길이 정보

---

문자열의 변경

CHAR , VARCHAR 타입을 결정할 때 중요한 판단 기준은 다음과 같습니다.

▶ 저장되는 문자열의 길이가 대개 비슷한가?

▶ 컬럼의 값이 자주 변경이 되는가?

타입을 결정하려면

해당 컬럼의 값이 얼마나 자주 변경하냐 가 기준이 돼야 한다.

CHAR( 9 ) , VARCHAR ( 9 ) 에 "CHOCO"를 저장한다면

● CHAR (10) 타입을 사용하는 crew_name 컬럼을 위해 공간이 9바이트 준비돼 있으므로

그냥 변경되는 값을 업데이트를 합니다.

● VARCHAR(10) 타입을 사용하는 컬럼에 5바이트 밖에 저장할 수 없는 구조로 만들어져 있습니다.

길이가 더 큰 값으로 변경될 때는 레코드 자체를 다른 공간으로 옮겨서 Row Migration 저장해야함.

​

주민등록번호 처럼 항상 값의 길이가 고정적일 때는 당연히 CHAR 타입을 사용해야 한다.

또한 값이 2~3바이트씩 차이가 나더라도 자주 변경될 수 있는 부서 번호나 게시물의 상태값 등은 CHAR 타입을 사용하는 것이 좋다.

자주 변경돼도 레코드가 물리적으로 다른 위치로 이동하거나 분리되지 않아도 되기 때문

레코드의 이동이나 분리는 CHAR 타입으로 인해 발생하는 2~3바이트 공간 낭비보다 더 큰 공간이나 자원을 낭비하게 만든다.

문자열 데이터 타입을 사용할 때 하나 주의사항이 있습니다.

CHAR 나 VARCHAR 키워드 뒤에 인자로 전달하는 숫자 값의 의미를 알아야 한다는 점.

​

▶ 일반적으로 영어를 포함한 서구권 언어는 각 문자가 1바이트를 사용하므로 10바이트를 사용

▶ 한국어나 아시아권 언어는 각 문자가 최대 2바이트를 사용하므로 20바이트를 사용

▶ UTF-8과 같은 유니코드는 최대 4바이트까지 사용하므로 40바이트 까지 사용이 가능

​

▶ 1바이트 저장 공간 사용 : 아스키(ASCII) 문자

▶ 2바이트 저장 공간 사용 : 추가 알파벳 문자

▶ 3바이트 저장 공간 사용 : BMP(Basic Multilingual) 문자

▶ 4바이트 저장 공간 사용 : SMP(Supplementary Multilingual Plane) & SIP(Supplementary Ideographic Plane)

​

BUT

이모티콘의 발전으로 예상외 심각한 문제가 되버렸다

MySQL서버는 이 문제를 해결하기 위해 utf8mb4라는 새로운 문자 집합

​

(UTF-8에서 이모티콘 바이트 크기 간단한건 4바이트 || 조합된 이모지는 4~16바이트 이상)

이모티콘	Unicode 코드 포인트	UTF-8 바이트 수
😄	U+1F604	4바이트
❤️	U+2764 + U+FE0F	6바이트
👩‍👩‍👦‍👦	조합된 코드 포인트	14바이트

결론 :

● CHAR

▶ 데이터를 읽기 / 쓰기 속도가 중요하고 길이가 고정되어 있다면 적합.

▶ 자주 변경되지 않는 데이터 필드에 사용

● VARCHAR

▶ 데이터 크기가 불규칙하고 공간 효율성을 고려해야 한다면 적합.

▶ 저장 공간이 중요한 환경에서 사용.

​

이러한 시스템의 우선순위를 고려 해서 선택 사용하면 될 것 같습니다.

(VARCHAR는 사용한다면 미리 조금 크게 설계하는것이 좋다고 합니다.)

 

참고자료:

https://velog.io/@chocochip/CHAR%EC%99%80-VARCHAR

CHAR와 VARCHAR