utf8_bin vs utf_unicode_ci

Question

Mi mesa Sitio web

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

que yo uso utf8_bin cotejo entonces mi consulta para buscar en Wikipedia Sitio web es

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

Y si uso utf8_unicode_ci entonces mi consulta de selección para buscar en Wikipedia en el sitio web es

Select Website_Name from Website where Website_Name='wikipedia' 

Ahora quiero saber cual es el mejor cotejo dependiendo de la SS debido a consultas

Answer 1

Depende de lo que necesite.

La intercalación utf8_bin compara las cadenas basadas únicamente en sus valores Unicode code point. Si todos los puntos de código tienen los mismos valores, entonces las cadenas son iguales. Sin embargo, esto se desmorona cuando tiene cadenas con composición diferente para combinar marcas (compuestas vs. descompuestas) o caracteres que son canónicamente equivalentes pero que no tienen el mismo valor de punto de código. En algunos casos, al usar utf8_bin, las cadenas no coincidirán cuando usted lo espera. Teóricamente, utf8_bin es el más rápido porque no se aplica la normalización Unicode a las cadenas, pero puede no ser lo que desea.

utf8_general_ci aplica la normalización Unicode usando reglas específicas del lenguaje y compara cadenas sin distinguir entre mayúsculas y minúsculas. utf8_general_cs hace lo mismo, pero compara las cadenas con mayúsculas y minúsculas.

Answer 2

Personalmente, me gustaría ir con utf8_unicode_ci, si espera que la letra no sea generalmente importante para los resultados que desea encontrar.

Las intercalaciones no solo se utilizan en tiempo de ejecución, sino también cuando MySQL crea índices. Por lo tanto, si cualquiera de estas columnas aparece en un índice, la búsqueda de datos de acuerdo con las reglas de comparación de esa intercalación será más rápida que nunca.

En aquellos casos en los que no desea la coincidencia de mayúsculas y minúsculas, entonces no aplique arriba o abajo. En su lugar, aplique la palabra clave BINARY al frente de la columna utf8 para forzar una comparación literal del punto de código en lugar de una de acuerdo con la intercalación.

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) 

Esto debería ser mucho más rápido que usar inferior o superior, ya que en esos casos, MySQL necesita primero hacer una copia del valor de la columna y modificar su mayúsculas y minúsculas, y luego aplicar la comparación. Con BINARY en su lugar, simplemente usará el índice primero para encontrar coincidencias, y luego hará un punto de código por comparación de punto de código hasta que encuentre que los valores no son iguales, lo que generalmente será más rápido.

Answer 3

que estaba usando 'utf8_unicode_ci', que es predeterminado por la doctrina, tuve que cambiarlo a:

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

Dado que algunas de las llaves primarias compuestas consistió en campos de texto. Tristemente, 'utf8_unicode_ci' resolvió "poistný" y "poistny" como el mismo valor de clave primaria y terminó con crash en doctrine inserting flush. No podía simplemente cambiar la intercalación de una parte de la clave primaria compuesta, tuve que eliminar la tabla y volver a crear. Espero que ahorre tiempo a otra persona ..