utf8 bin vs. utf unicode ci
Moja strona tabeli
Website_Name//column name
Google
Facebook
Twitter
Orkut
Frype
Skype
Yahoo
Wikipedia
Używam kompilacji utf8_bin, a moje zapytanie do wyszukiwania Wikipedii w witrynie to
Select Website_Name from Website where lower(Website_Name)='wikipedia'
A jeśli używam utf8_unicode_ci to moje zapytanie select do wyszukiwania Wikipedii w witrynie to
Select Website_Name from Website where Website_Name='wikipedia'
Teraz chcę wiedzieć, które zestawienie jest najlepsze w zależności od następujących zapytań
3 answers
To zależy, czego potrzebujesz.
Klasyfikacja utf8_bin porównuje ciągi znaków wyłącznie na podstawie ich wartości punktu kodu Unicode . Jeśli wszystkie punkty kodu mają takie same wartości, to ciągi znaków są równe. Jednak to się rozpada, gdy masz ciągi znaków o innym składzie do łączenia znaków (złożony vs rozłożony) lub znaki, które są kanonicznie równoważne, ale nie mają tej samej wartości punktu kodu. W niektórych przypadkach użycie utf8_bin spowoduje, że łańcuchy nie pasują, gdy oczekujesz tego. Teoretycznie utf8_bin jest najszybszy, ponieważ do łańcuchów nie stosuje się normalizacji Unicode, ale może to nie być to, czego chcesz.
utf8_general_ci stosuje normalizację Unicode przy użyciu reguł specyficznych dla języka i porównuje znaki bez rozróżniania wielkości liter. utf8_general_cs robi to samo, ale porównuje wielkość liter ze względu na wielkość liter.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-02 23:45:47
Osobiście wybrałbym utf8_unicode_ci, jeśli spodziewasz się, że skrzynka na listy nie jest zasadniczo ważna dla wyników, które chcesz znaleźć.
Kolacje są używane nie tylko podczas wykonywania, ale także podczas kompilacji indeksów MySQL. Jeśli więc którakolwiek z tych kolumn pojawi się w indeksie, znalezienie danych zgodnie z regułami porównywania tego zestawienia będzie tak szybkie, jak kiedykolwiek.
W przypadkach, w których nie chcesz dopasowywać wielkości bez rozróżniania wielkości liter, nie stosuj upper ani lower. Zamiast, zastosuj słowo kluczowe BINARY przed kolumną utf8, aby wymusić dosłowne porównanie punktów kodu, a nie jedno zgodnie z zestawieniem.
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)
Powinno to być znacznie szybsze niż użycie lower lub upper, ponieważ w takich przypadkach MySQL musi najpierw wykonać kopię wartości kolumny i zmodyfikować jej skrzynkę na listy, a następnie zastosować porównanie. Z binarnym w miejscu będzie po prostu użyć indeksu najpierw znaleźć dopasowania, a następnie zrobić kod-punkt przez kod-punkt porównania, dopóki nie znajdzie wartości są nie równe, co na ogół będzie szybsze.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-06-07 10:40:57
Używałem 'utf8_unicode_ci', które jest domyślne przez doktrynę, musiałem zmienić na:
* @ORM\Table(name = "Table", options={"collate"="utf8_bin"})
Ponieważ niektóre z moich złożonych kluczy podstawowych składały się z pól tekstowych. Niestety 'utf8_unicode_ci' rozwiązał "poistný" i "poistny" jako tę samą wartość klucza podstawowego i zakończył się crashem przy wstawianiu flush. Nie mogłem po prostu zmienić zestawiania jednej części złożonego klucza podstawowego, musiałem upuścić tabelę i odtworzyć. Mam nadzieję, że to zaoszczędzi czas komuś innemu..
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-02-18 13:24:25