MySQL 백업 문자 세트에 대한 토론

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

1 소개

MySQL을 백업할 때 문자 집합을 선택하는 것은 어려운 문제이며, 특히 불확실한 문자 집합을 가진 기업의 경우. Mysqldump는 기본적으로 utf8을 사용하며, 공식적으로도 utf8을 권장합니다. 그러나 실제로 중국어의 경우 gbk로 인코딩된 문자의 상당 부분에는 해당 유니코드 인코딩이 없습니다. 즉, 문자 집합의 이 부분에 대해 utf8 백업을 사용하면 데이터가 손실될 수 있습니다. 그렇다면 해결책이 있나요?

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

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

2 바이너리 문제

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

2.1 utf8 backup

(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 인코딩으로 지정되면 필연적으로 가져오기가 실패합니다.

예:

CREATE TABLE `t1`(

`iNetbarId` int(11) NOT NULL DEFAULT '0',

`iUin` bigint(20) NOT NULL DEFAULT '0',

`vNetbarName` varchar(80) NOT NULL DEFAULT '"-"',

PRIMARY KEY (`iNetbarId`)

) ENGINE=InnoDB DEFAULT CHARSET=gbk;

t1 값에 삽입(1,1,' xxxx');

정상적으로 익스포트된 테이블이 1067 에러와 함께 임포트된 것을 확인할 수 있습니다. 기본값이 잘못되었습니다.

3 해결 방법

mysqldump를 사용할 때 create table 문을 실행하기 전에 Character_set_connection 설정을 추가하세요.

/*!40101 SET Character_set_connection = utf8 */

이것도 MySQL의 버그입니다. 스키마 정보가 처음부터 끝까지 utf8을 사용하기 때문에 create table을 실행하기 전에 연결 문자 집합을 변경해야 합니다. 클라이언트의 문자 집합 변수를 설정하는 대신 변수가 utf8로 설정됩니다.

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