MySQL 백업 문자셋 문제에 대한 간략한 논의

[소개] 1 소개 MySQL을 백업할 때 문자 집합을 선택하는 것은 어려운 문제이며, 특히 가변 문자 집합을 사용하는 기업의 경우 더욱 그렇습니다. Mysqldump는 기본적으로 utf8을 사용하며, 공식적으로도 utf8을 권장합니다. 그러나 실제로 중국어의 경우 상당수의 gbk로 인코딩된 문자에 해당하는 유니코드 인코딩이 없습니다. 이는 문자 집합의 이 부분이

1 소개

백업 시 문자 집합 선택을 의미합니다. up MySQL은 특히 가변 문자 세트를 사용하는 비즈니스에서는 어려운 문제입니다. mysqldump는 기본적으로 utf8을 사용하며, utf8도 공식적으로 권장됩니다. 그러나 실제로 중국어의 경우 gbk로 인코딩된 문자의 상당 부분에는 해당 유니코드 인코딩이 없습니다. 즉, 문자 집합의 이 부분에 대해 utf8 백업을 사용하면 데이터가 손실될 수 있습니다. 그렇다면 해결책이 있나요?

물론 가장 직접적인 방법은 인코딩의 이 부분에 대한 매핑을 추가하는 것입니다. 그런데 이 부분의 문자 집합의 개수가 적지 않고, 더욱 짜증나는 점은 이 부분의 문자 집합에 대한 권위 있는 매핑 표준이 없는 것 같다는 점입니다. 그럼 다른 방법은 없나요?

사실 바이너리를 사용하여 백업을 하면 문자셋 변환 과정도 없어 위와 같은 문제도 발생하지 않습니다. 그렇다면 바이너리를 사용하면 gbk의 모든 문제가 해결됩니까? 대답은 '아니요'입니다.

바이너리 문제 2개

바이너리 문제에 대해 이야기하기 전에. 명확히 해야 할 질문이 2개 있습니다. MySQL 백업의 경우 스키마 정보와 실제 데이터 두 부분으로 나누어집니다. 스키마 정보는 기본값을 제외하고 항상 utf8로 인코딩됩니다. 여기서 문제가 발생합니다.

2.1 utf8 백업

(1) .frm 파일에는 테이블의 스키마 정보가 저장되며, 실제 레코드를 통해 각 필드의 기본값이 저장됩니다. Schema에 해당하는 정보(코멘트 포함)는 utf8을 사용하여 저장되나, 기본값은 테이블에서 지정한 문자셋을 사용하여 저장된다.

(2) show create table 문을 실행할 때 mysqld는 frm의 기본값을 테이블에 지정된 인코딩에서 utf8 인코딩으로 변환합니다.

(3) mysqld가 create table 문을 실행할 때 기본값은 utf8에서 테이블에 지정된 문자 집합으로 변환됩니다.

2.2 바이너리 백업

백업 대상으로 바이너리를 지정한 경우. 가져올 때 테이블을 생성하기 전에는 Character_set_client가 utf8로 지정되어 있지만 collation_connection은 여전히 ​​바이너리입니다. 따라서 기본값을 저장할 때 utf8에서 테이블에 지정된 문자 세트로의 변환이 수행되지 않습니다. 테이블이 gbk 인코딩으로 지정되면 필연적으로 가져오기가 실패합니다.

예:

위 내용은 MySQL 백업 문자셋 문제에 대한 간략한 논의의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!