programing

utf8_bin vs. utf_bin_ci

batch 2023. 7. 30. 17:31
반응형

utf8_bin vs. utf_bin_ci

내 테이블 웹 사이트

Website_Name//column name
Google
Facebook
Twitter
Orkut
Frype
Skype
Yahoo
Wikipedia

저는 utf8_bin colation을 사용합니다. 그러면 웹사이트에서 위키백과를 검색하기 위한 제 질문은 다음과 같습니다.

Select Website_Name from Website where lower(Website_Name)='wikipedia'

그리고 만약 내가 utf8_unicode_ci를 사용한다면, 웹사이트에서 위키백과를 검색하기 위한 나의 선택 질의는 다음과 같습니다.

Select Website_Name from Website where Website_Name='wikipedia'

이제 다음 쿼리에 따라 어떤 컬렉션이 가장 좋은지 알고 싶습니다.

당신이 어떤 도움을 필요로 하느냐에 따라 다르겠죠.

utf8_bin데이터 정렬은 유니코드 코드 포인트 값을 기준으로 문자열을 비교합니다.모든 코드 포인트의 값이 같으면 문자열은 동일합니다.그러나 마크를 결합하기 위한 구성이 다른 문자열(합성된 문자열과 분해된 문자열)이 있거나 표준적으로 동일하지만 코드 포인트 값이 동일하지 않은 문자가 있는 경우에는 이 값이 적용되지 않습니다.경우에 따라, 사용utf8_bin문자열이 일치하지 않을 것으로 예상할 때 일치하지 않습니다.이론적으로는utf8_bin유니코드 정규화가 문자열에 적용되지 않기 때문에 가장 빠르지만 원하는 것이 아닐 수 있습니다.

utf8_general_ci은 언어별 규칙을 사용하여 유니코드 정규화를 적용하고 문자열을 대소문자를 구분하지 않고 비교합니다.utf8_general_cs동일하지만 문자열은 대소문자를 구분하여 비교합니다.

개인적으로 저는 같이 갈 것입니다.utf8_unicode_ci일반적으로 원하는 결과에 대해 대소문자가 중요하지 않다고 생각하는 경우.

데이터 정렬은 런타임에만 사용되는 것이 아니라 MySQL이 인덱스를 작성할 때도 마찬가지입니다.따라서 이러한 열 중 하나가 인덱스에 나타나면 비교 규칙에 따라 데이터를 찾는 작업이 훨씬 빨라집니다.

대소문자를 구분하지 않는 일치를 원하지 않는 경우에는 상위 또는 하위를 적용하지 않습니다.대신 다음을 적용합니다.BINARYutf8 열 앞에 있는 키워드를 사용하여 정렬에 따라 하나가 아닌 문자 코드 포인트 비교를 수행합니다.

mysql> create table utf8 (name varchar(24) charset utf8 collate utf8_general_ci, primary key (name));
Query OK, 0 rows affected (0.14 sec)

mysql> insert into utf8 values ('Roland');
Query OK, 1 row affected (0.00 sec)

mysql> insert into utf8 values ('roland');
ERROR 1062 (23000): Duplicate entry 'roland' for key 'PRIMARY'
mysql> select * from utf8 where name = 'roland';
+--------+
| name   |
+--------+
| Roland |
+--------+
1 row in set (0.00 sec)

mysql> select * from utf8 where binary name = 'roland';
Empty set (0.01 sec)

이 경우 MySQL은 먼저 열 값의 복사본을 만들고 문자 대소문자를 수정한 다음 비교를 적용해야 하기 때문에 이 작업은 낮음 또는 높음을 사용하는 것보다 훨씬 빨라야 합니다.BINARY를 사용하면 먼저 인덱스를 사용하여 일치 항목을 찾은 다음 값이 동일하지 않다는 것을 발견할 때까지 코드 포인트별 비교를 수행하면 일반적으로 더 빠릅니다.

교리상 기본값인 'utf8_unicode_ci'를 사용하고 있었는데, 다음으로 변경해야 했습니다.

 * @ORM\Table(name = "Table", options={"collate"="utf8_bin"})

내 복합 기본 키 중 일부가 텍스트 필드로 구성되었기 때문입니다.슬프게도 'utf8_unicode_ci'는 "poistný"와 "poistny"를 동일한 기본 키 값으로 확인하고 dutrince flush를 삽입할 때 충돌로 끝났습니다.복합 기본 키의 한 부분을 단순히 변경할 수 없었기 때문에 테이블을 삭제하고 다시 만들어야 했습니다.다른 사람에게 시간이 절약되기를 바랍니다.

언급URL : https://stackoverflow.com/questions/10929836/utf8-bin-vs-utf-unicode-ci

반응형