10.1.11 이전 Unicode 지원에서 현재 Unicode 지원으로 업그레이드
이 섹션에서는 이전 MySQL 버전에서 MySQL 5.6으로 업그레이드 할 때 일어날 수있는 Unicode 지원 문제에 대해 설명합니다. 또한 MySQL 5.6에서 이전 릴리스로 다운 그레이드하는 지침도 제공합니다.
대부분의 점에서 MySQL 5.6으로 업그레이드해도 Unicode 사용에 대한 문제가 발생할 일은 거의 없지만, 비 호환성 수있는 몇 가지 영역이 있습니다. 주요 대상 지역은 다음과 같습니다.
가변 길이 데이터 형 (
VARCHAR
형과TEXT
형)의 경우, 문자의 최대 길이는utf8mb4
열 쪽이utf8
컬럼보다 짧아집니다.모든 문자 데이터 유형 (
CHAR
형,VARCHAR
형 및TEXT
형)에서 인덱스를 붙일 수있는 최대 문자 수는utf8mb4
열 쪽이utf8
컬럼보다 적습니다.
따라서 utf8
에서 utf8mb4
테이블을 업그레이드하고 보조 문자 지원을 사용할 경우 일부 열 또는 인덱스 정의를 변경해야 할 수 있습니다.
테이블은 ALTER TABLE
을 사용하여 utf8
에서 utf8mb4
로 변환 할 수 있습니다. 테이블이 원래 다음과 같이 정의되어 있었다고합니다.
CREATE TABLE t1 ( col1 CHAR (10) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, col2 CHAR (10) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL ) CHARACTER SET utf8;
다음 문은 utf8mb4
를 사용하도록 t1
을 변환합니다.
ALTER TABLE t1 DEFAULT CHARACTER SET utf8mb4, MODIFY col1 CHAR (10) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, MODIFY col2 CHAR (10) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL;
테이블의 내용은 utf8
에서 utf8mb4
로 변환 문제가 발생하지 않습니다.
BMP 문자의 경우
utf8
로utf8mb4
스토리지 특성은 동일 코드 값 인코딩 길이가 동일합니다.보조 문자 내용은
utf8
이 문자를 전혀 포함하지 않지만utf8mb4
문자를 저장하는 데 4 바이트를 필요로합니다.utf8
이 문자를 전혀 포함하지 않기 때문에,utf8
컬럼에는 보조 문자가 아닌utf8
데이터를 이전 버전의 MySQL에서 업그레이드 할 때, 문자의 변환이나 데이터 손실에 대해 걱정할 필요가 없습니다.
테이블 구조는 utf8
에서 utf8mb4
로 변환 할 때 열 또는 인덱스 키의 최대 길이가 바이트의 점에서 변경되지 않는 문제가 발생합니다. 따라서 문자의 최대 길이가 3 대신 4이므로, 문자의 점에서 이것은 더 작아집니다. CHAR
, VARCHAR
및 TEXT
데이터 형의 경우 MySQL 테이블을 변환 할 때 다음 사항에주의하십시오.
utf8
컬럼의 모든 정의를 조사하여 그들이 스토리지 엔진의 최대 길이를 초과하지 않았는지 확인합니다.utf8
컬럼의 모든 인덱스를 조사하여 그들이 스토리지 엔진의 최대 길이를 초과하지 않았는지 확인합니다. 최대 값은 스토리지 엔진의 기능 강화에 따라 변경 될 수 있습니다.
위의 조건에 해당하는 경우에는 열 또는 인덱스의 정의 된 길이를 줄이거 utf8mb4
아닌 utf8
을 계속해야합니다.
그런 구조적인 변경이 필요한 몇 가지 예를 보여줍니다.
TINYTEXT
열은 최대 255 바이트를 저장할 수 있기 때문에 3 바이트 문자는 85 개의 4 바이트 문자는 63 개까지 저장할 수 있습니다.utf8
을 사용하는TINYTEXT
컬럼이 있지만, 63 개 이상의 문자를 포함되는 것이 필요하다고합니다. 데이터 형도TEXT
등의 더 긴 형태로 변경하지 않는 한이를utf8mb4
로 변환 할 수 없습니다.마찬가지로 매우 긴
VARCHAR
컬럼은utf8
에서utf8mb4
로 변환하려면 더 긴TEXT
형 중 하나로 변경해야합니다.InnoDB
는COMPACT
또는REDUNDANT
행 형식을 사용하는 테이블에 767 바이트의 최대 인덱스 길이가 있고utf8
또는utf8mb4
컬럼의 경우 각각 255 또는 191 개의 문자를 인덱싱 할 수 있습니다. 현재 인덱스가 191 개의 문자보다 긴utf8
열이있는 경우 인덱싱 할 문자 수를 줄여야합니다.COMPACT
또는REDUNDANT
행 형식을 사용하는InnoDB
테이블에서 다음 컬럼 및 인덱스 정의가 유효합니다.col1 VARCHAR (500) CHARACTER SET utf8, INDEX (col1 (255))
대신
utf8mb4
를 사용하려면 인덱스를 더 작게 할 필요가 있습니다.col1 VARCHAR (500) CHARACTER SET utf8mb4, INDEX (col1 (191))
참고COMPRESSED
또는DYNAMIC
행 형식을 사용하는InnoDB
테이블의 경우innodb_large_prefix
옵션을 활성화하면 767 바이트보다 긴 인덱스 키 프리픽스 (최대 3072 바이트)를 허용 할 수 있습니다. 이러한 테이블의 생성에는innodb_file_format=barracuda
및innodb_file_per_table=true
옵션 값도 필요합니다. )이 경우innodb_large_prefix
옵션을 사용하면utf8
또는utf8mb4
컬럼에 대해 각각 최대 1024 또는 768 개의 문자를 인덱싱 할 수 있습니다. 자세한 내용은 섹션 14.6.7 "InnoDB 테이블에서의 제한" 을 참조하십시오.
전술의 변경 유형은 매우 긴 컬럼 또는 인덱스를 가지는 경우에만 필요하게 될 가능성이 높아집니다. 그렇지 않으면 utf8
에서 utf8mb4
에 문제없이 테이블을 변환 할 수 있습니다. 이렇게는 5.6에서 제대로 업그레이드 한 후이 절에서 이미 언급 한 바와 같이 ALTER TABLE
을 사용합니다.
다음 항목은 비 호환성 수있는 다른 영역에 대해 정리 한 것입니다.
4 바이트 UTF-8 (
utf8mb4
)의 성능은 3 바이트 UTF-8 (utf8
)의 성능보다 떨어집니다. 이 페널티하지 않으려는utf8
을 계속 사용하십시오.SET NAMES 'utf8mb4'
는 연결 문자 세트에 4 바이트 문자 집합을 사용해야합니다. 4 바이트 문자가 서버에서 전송되지 않는 한 문제가 발생하지 않습니다. 그렇지 않으면, 캐릭터 당 최대 3 바이트의 수신을 요구하는 응용 프로그램에 문제가 발생할 수 있습니다. 반대로, 4 바이트의 문자 전송을 요구하는 어플리케이션은 그 문자가 서버에서 인식되는지 확인해야합니다.응용 프로그램은
utf16
,utf16le
또는utf32
문자 데이터를 인식하지 못하는 오래된 서버에 이러한 데이터를 보낼 수 없습니다.복제는 보조 문자를 지원하는 문자 세트가 마스터로 사용되는 경우 모든 슬레이브에서도 이러한 문자를 인식해야합니다. MySQL 5.6 마스터에서 오래된 슬레이브에 복제하려고 할 때
utf8
데이터는 슬레이브에서utf8
로 인식되고 올바르게 복제됩니다. 그러나utf8mb4
,utf16
,utf16le
또는utf32
데이터를 보낼 수 없습니다.또한 테이블에 마스터와 슬레이브에 대해 다른 정의가있는 경우 예상치 못한 결과를 초래할 수 있다는 일반적인 원칙에 유의하십시오. 예를 들어, 인덱스 키 길이의 제한이 다른 마스터에서
utf8
을 사용하여 슬레이브에서utf8mb4
를 사용하는 것은 위험합니다.
MySQL 5.6으로 업그레이드하고 있으며, 이전 릴리스로 다운 그레이드하기로 한 경우 다음 고려 사항이 적용됩니다.
ucs2
및utf8
데이터에 문제가 발생하지 않아야합니다.utf8mb4
,utf16
,utf16le
또는utf32
문자 집합을 참조하는 모든 정의는 기존 서버에서 인식되지 않습니다.utf8mb4
문자 집합을 참조하는 객체 정의의 경우 데이터에 4 바이트 문자가 존재하지 않는 한, MySQL 5.6에서 mysqldump를 사용하여 이러한 덤프하고utf8mb4
의 인스턴스를utf8
로 변경하도록 덤프 파일을 편집합니다 이 파일을 기존 서버에 다시로드 할 수 있습니다. 이전 서버는 덤프 파일 객체 정의의utf8
을 인식하고 (3 바이트)utf8
문자 집합을 사용하는 새로운 객체를 작성합니다.