13.3.2 The CHAR and VARCHAR Types

13.3.2 The CHAR and VARCHAR Types

CHAR 및 VARCHAR 타입은 유사하지만, 저장되고 조회되는 방식이 다릅니다. 또한 최대 길이와 뒤따르는 공백을 유지하는지 여부도 다릅니다.

CHAR 및 VARCHAR 타입은 저장하려는 최대 문자 수를 나타내는 길이와 함께 선언합니다. 예를 들어, CHAR(30)은 최대 30자를 저장할 수 있습니다.

CHAR 컬럼의 길이는 테이블을 생성할 때 선언한 길이로 고정됩니다. 길이는 0에서 255 사이의 값이 될 수 있습니다. CHAR 값이 저장될 때는 지정된 길이가 되도록 오른쪽에 공백이 채워집니다. CHAR 값을 조회할 때는 PAD_CHAR_TO_FULL_LENGTH SQL 모드가 활성화되어 있지 않은 한, 뒤따르는 공백이 제거됩니다.

VARCHAR 컬럼의 값은 가변 길이 문자열입니다. 길이는 0에서 65,535 사이의 값으로 지정할 수 있습니다. VARCHAR의 실질적인 최대 길이는 최대 로우 크기(65,535바이트, 모든 컬럼이 공유)와 사용되는 문자 집합에 의해 제한됩니다. Section 10.4.7, “Limits on Table Column Count and Row Size”를 참조하십시오.

CHAR와 달리, VARCHAR 값은 1바이트 또는 2바이트 길이 프리픽스와 데이터로 저장됩니다. 길이 프리픽스는 값의 바이트 수를 나타냅니다. 값이 최대 255바이트만 필요한 경우 컬럼은 1바이트 길이 프리픽스를 사용하고, 255바이트를 초과할 수 있는 값을 허용하는 경우에는 2바이트 길이 프리픽스를 사용합니다.

strict SQL 모드가 활성화되어 있지 않을 때 CHAR 또는 VARCHAR 컬럼에 컬럼의 최대 길이를 초과하는 값을 할당하면, 그 값은 맞도록 잘려(truncate) 저장되고 경고가 발생합니다. 공백이 아닌 문자가 잘리는 경우, strict SQL 모드를 사용하여 경고 대신 에러가 발생하도록 하고 값의 삽입을 억제할 수 있습니다. Section 7.1.11, “Server SQL Modes”를 참조하십시오.

VARCHAR 컬럼의 경우, 컬럼 길이를 초과하는 뒤따르는 공백은 삽입 전에 잘려서 저장되며, 사용 중인 SQL 모드와 관계없이 경고가 발생합니다. CHAR 컬럼의 경우, 삽입되는 값에서 초과된 뒤따르는 공백을 잘라내는 작업은 SQL 모드와 상관없이 조용히 수행됩니다.

VARCHAR 값은 저장될 때 패딩 처리되지 않습니다. 뒤따르는 공백은 값이 저장되고 조회될 때 유지되며, 표준 SQL을 준수합니다.

다음 표는 CHAR와 VARCHAR의 차이를 보여 주기 위해, 다양한 문자열 값을 CHAR(4) 및 VARCHAR(4) 컬럼에 저장했을 때의 결과를 나타냅니다(단, 컬럼이 latin1과 같은 단일 바이트 문자 집합을 사용한다고 가정합니다).

Value	CHAR(4)	Storage Required	VARCHAR(4)	Storage Required
''	'    '	4 bytes	''	1 byte
'ab'	'ab  '	4 bytes	'ab'	3 bytes
'abcd'	'abcd'	4 bytes	'abcd'	5 bytes
'abcdefgh'	'abcd'	4 bytes	'abcd'	5 bytes

표의 마지막 행에 저장된 값은 strict SQL 모드를 사용하지 않을 때에만 적용됩니다. strict 모드가 활성화되어 있으면 컬럼 길이를 초과하는 값은 저장되지 않으며, 에러가 발생합니다.

InnoDB는 길이가 768바이트 이상인 고정 길이 필드를 가변 길이 필드로 인코딩하여 페이지 밖에 저장할 수 있게 합니다. 예를 들어, 문자 집합의 최대 바이트 길이가 3보다 큰 경우(예: utf8mb4), CHAR(255) 컬럼은 768바이트를 초과할 수 있습니다.

특정 값을 CHAR(4)와 VARCHAR(4) 컬럼에 저장하면, 조회된 값은 항상 동일하지 않을 수 있는데, 이는 조회 시 CHAR 컬럼에서 뒤따르는 공백이 제거되기 때문입니다. 다음 예는 이러한 차이를 보여 줍니다:

1mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
2Query OK, 0 rows affected (0.01 sec)
3
4mysql> INSERT INTO vc VALUES ('ab  ', 'ab  ');
5Query OK, 1 row affected (0.00 sec)
6
7mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
8+---------------------+---------------------+
9| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
10+---------------------+---------------------+
11| (ab  )              | (ab)                |
12+---------------------+---------------------+
131 row in set (0.06 sec)

CHAR, VARCHAR, TEXT 컬럼의 값은 컬럼에 할당된 문자 집합 정렬 규칙에 따라 정렬되고 비교됩니다.

MySQL 정렬 규칙은, UCA 9.0.0 이상을 기반으로 하는 유니코드 정렬 규칙을 제외하고는, PAD SPACE 패딩 속성을 가집니다. UCA 9.0.0 이상 기반 유니코드 정렬 규칙은 NO PAD 패딩 속성을 가집니다. (Section 12.10.1, “Unicode Character Sets” 참조).

정렬 규칙의 패딩 속성을 확인하려면 INFORMATION_SCHEMA COLLATIONS 테이블을 사용하십시오. 이 테이블에는 PAD_ATTRIBUTE 컬럼이 있습니다.

논바이너리 문자열(CHAR, VARCHAR, TEXT 값)의 경우, 문자열 정렬 규칙 패딩 속성은 문자열 끝의 뒤따르는 공백을 비교할 때의 처리 방식을 결정합니다. NO PAD 정렬 규칙은 뒤따르는 공백을 다른 문자와 마찬가지로 비교 시 유의미하게 취급합니다. PAD SPACE 정렬 규칙은 뒤따르는 공백을 비교 시 의미 없는 것으로 취급하며, 뒤따르는 공백을 무시하고 문자열을 비교합니다. Trailing Space Handling in Comparisons를 참조하십시오. 서버 SQL 모드는 뒤따르는 공백과 관련된 비교 동작에 아무런 영향을 미치지 않습니다.

참고

MySQL 문자 집합 및 정렬 규칙에 관한 더 많은 정보는 Chapter 12, Character Sets, Collations, Unicode를 참조하십시오. 저장 공간 요구 사항에 대한 추가 정보는 Section 13.7, “Data Type Storage Requirements”를 참조하십시오.

뒤따르는 패딩 문자들이 제거되거나 비교 시 무시되는 경우, 컬럼에 유니크 값이 필요한 인덱스가 있다면, 그 컬럼에 뒤따르는 패딩 문자의 개수만 다른 값을 삽입하려고 할 때 중복 키 에러가 발생합니다. 예를 들어, 테이블에 'a'가 들어 있는 상태에서 'a '를 저장하려고 하면 중복 키 에러가 발생합니다.