utf8_bin vs. utf_unicode_ci

Question

Moja tabela WWW

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

ja używam utf8_bin zestawień wtedy mój zapytań do wyszukiwania wikipedia w Serwisie jest

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

A jeśli używam utf8_unicode_ci wtedy mój kwerendę wybierającą, aby szukać wikipedia na stronie internetowej:

Select Website_Name from Website where Website_Name='wikipedia' 

Teraz chcę wiedzieć, które sortowanie jest najlepsze w zależności od foll należne zapytania

Answer 1

To zależy od tego, czego potrzebujesz.

Sortowanie porównuje ciągi oparte wyłącznie na ich wartościach Unicode. Jeśli wszystkie punkty kodowe mają te same wartości, łańcuchy są równe. Jednak to się rozpada, gdy masz łańcuchy o różnym składzie do łączenia znaków (skomponowane lub rozłożone) lub znaki, które są kanonicznie równoważne, ale nie mają tej samej wartości punktu kodowego. W niektórych przypadkach użycie parametru utf8_bin spowoduje, że ciągi nie będą pasować, gdy tego oczekujesz. Teoretycznie, utf8_bin jest najszybszy, ponieważ żadna normalizacja Unicode nie jest stosowana do łańcuchów, ale może nie być to, co chcesz.

utf8_general_ci stosuje normalizację Unicode przy użyciu reguł specyficznych dla języka i porównuje ciągi znaków bez rozróżniania wielkości liter. utf8_general_cs robi to samo, ale porównuje ciągi znaków z uwzględnieniem wielkości liter.

Answer 2

Osobiście chciałbym wybrać z utf8_unicode_ci, jeśli spodziewasz się, że litera nie jest ogólnie ważna dla wyników, które chcesz znaleźć.

Zbiory są używane nie tylko w środowisku wykonawczym, ale także wtedy, gdy MySQL tworzy indeksy. Jeśli więc którakolwiek z tych kolumn pojawi się w indeksie, znalezienie danych zgodnie z regułami porównania tego sortowania będzie prawie tak szybkie, jak to tylko możliwe.

W przypadkach, gdy nie chcesz dopasowywania wielkości liter, nie stosuj górnej ani dolnej. Zamiast tego zastosuj słowo kluczowe BINARY przed kolumną utf8, aby wymusić dosłowne porównanie kodu, a nie jedno zgodnie z sortowaniem.

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) 

ten powinien być znacznie szybszy niż przy użyciu dolne lub górne, ponieważ w tych przypadkach, MySQL musi najpierw zrobić kopię wartości kolumny i zmodyfikować jego lettercase, a następnie zastosować porównanie. Gdy BINARY będzie na miejscu, użyje najpierw indeksu do znalezienia dopasowań, a następnie porówna kod, dopóki nie stwierdzi, że wartości nie są równe, co generalnie będzie szybsze.

Answer 3

używałem „utf8_unicode_ci”, który jest domyślnym przez doktrynę, musiałem go zmienić na:

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

Ponieważ niektóre z moich złożonych kluczy podstawowych składała się z pól tekstowych. Niestety "utf8_unicode_ci" rozwiązało "poistný" i "poistny" jako tę samą wartość klucza podstawowego i zakończyło się zawieszeniem na doktrynie wstawiania koloru. Nie mogłem po prostu zmienić sortowania jednej części złożonego klucza podstawowego, musiałem upuścić tabelę i odtworzyć. Mam nadzieję, że to oszczędza czas komuś innemu ..