utf8_bin vs. utf_unicode_ci

Question

Meine Tabelle Webseite

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

I i utf8_bin Sortierung verwenden dann meine Abfrage wikipedia in Webseite ist

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

Und wenn ich verwenden utf8_unicode_ci dann meine SELECT-Abfrage zu suchen, um die Suche wikipedia in der Website ist

Select Website_Name from Website where Website_Name='wikipedia' 

Jetzt möchte ich wissen, welche Kollation ist am besten abhängig von der Foll wegen Fragen

Answer 1

Es hängt davon ab, was Sie brauchen.

Die utf8_bin Kollation vergleicht Zeichenfolgen, die ausschließlich auf ihren Unicode code point Werten basieren. Wenn alle Codepunkte dieselben Werte haben, sind die Strings gleich. Dies fällt jedoch auseinander, wenn Sie Zeichenfolgen mit unterschiedlicher Zusammensetzung zum Kombinieren von Zeichen (zusammengesetzt oder zerlegt) oder Zeichen haben, die kanonisch äquivalent sind, aber nicht den gleichen Codepunktwert haben. In einigen Fällen führt die Verwendung von utf8_bin dazu, dass die Zeichenfolgen nicht übereinstimmen, wenn Sie dies erwarten. Theoretisch ist utf8_bin der schnellste, da keine Unicode-Normalisierung auf die Strings angewendet wird, aber es ist möglicherweise nicht das, was Sie wollen.

utf8_general_ci wendet Unicode-Normalisierung unter Verwendung von sprachenspezifischen Regeln an und vergleicht Zeichenketten fallunabhängig. utf8_general_cs macht das gleiche, vergleicht aber Zeichenfolgen in Groß- und Kleinschreibung.

Answer 2

Persönlich würde ich mit utf8_unicode_ci gehen, wenn Sie erwarten, dass Briefkasten im Allgemeinen nicht wichtig ist für die Ergebnisse, die Sie finden möchten.

Collations werden nicht nur zur Laufzeit verwendet, sondern auch, wenn MySQL Indizes erstellt. Wenn also eine dieser Spalten in einem Index erscheint, wird das Finden von Daten gemäß den Vergleichsregeln dieser Kollatierung so schnell wie möglich sein.

In den Fällen, in denen keine Groß-/Kleinschreibung beachtet werden soll, gelten sie nicht für die obere oder untere Ebene. Wenden Sie stattdessen das Schlüsselwort BINARY vor der Spalte utf8 an, um einen literalen Code-Point-Vergleich zu erzwingen, und nicht einen Vergleich nach der Sortierung.

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) 

Dies sollte viel schneller sein als die untere oder obere verwenden, da in diesen Fällen MySQL muss zunächst eine Kopie der Spalte Wert machen und seine Schreibweise ändern, und dann den Vergleich gelten. Wenn BINARY vorhanden ist, wird einfach der Index zuerst verwendet, um Übereinstimmungen zu finden, und dann wird ein Codepunkt durch Codepunktvergleich durchgeführt, bis die Werte nicht gleich sind, was im Allgemeinen schneller ist.

Answer 3

Ich war mit ‚utf8_unicode_ci‘, die standardmäßig von Lehre ist, musste ich es ändern:

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

Da einige meiner zusammengesetzten Primärschlüssel von Textfeldern bestand. Traurigerweise löste 'utf8_unicode_ci' "poistný" und "poistny" als gleichen Primärschlüsselwert und endete mit einem Absturz beim Einfügen von Flush. Ich konnte nicht einfach die Sortierung eines Teils des zusammengesetzten Primärschlüssels ändern, musste die Tabelle löschen und neu erstellen. Hoffe, es spart Zeit für jemand anderen ..