2012-09-16 36 views
12

¿Cuáles son las ventajas/desventajas entre utilizar utf8 como juego de caracteres contra el uso de latin1?utf-8 vs latin1

Si utf puede admitir más caracteres y se utiliza de forma consistente, ¿no sería siempre la mejor opción? ¿Hay alguna razón para elegir latin1?

+0

Utilice siempre 'utf8mb4' y no' utf8' - [es un tipo de error de MySQL] (https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434) – xmedeko

Respuesta

10

latin1 tiene la ventaja de que es una codificación de un solo byte, por lo tanto, puede almacenar más caracteres en la misma cantidad de espacio de almacenamiento porque la longitud de los tipos de datos de cadena en MySql depende de la codificación. El manual states que

para calcular el número de bytes utilizados para almacenar un CHAR en particular, VARCHAR, o el valor de la columna de texto, debe tener en cuenta el conjunto carácter utilizado para esa columna y si el valor contiene caracteres de varios bytes. En particular, cuando se utiliza el conjunto de caracteres Unicode utf8 (o utf8mb4) , debe tener en cuenta que no todos los caracteres usan el mismo número de bytes y pueden requerir hasta tres (cuatro) bytes por carácter. Para ver un desglose del almacenamiento utilizado para las diferentes categorías de caracteres utf8 o utf8mb4, consulte la Sección 10.1.10, "Soporte Unicode".

Además, muchas operaciones de cadena (como la toma de subcadenas y comparaciones dependientes de la intercalación) son más rápidas con las codificaciones de un solo byte.

En cualquier caso, latin1 no es un contendiente serio si le importa la internacionalización en absoluto. Puede ser una opción adecuada cuando almacene valores seguros conocidos (como URL codificadas por porcentaje).

+0

¿También es compatible con otros lenguajes Unicode? Hebreo en particular? – qwertymk

+0

No es compatible con hebreo, @qwertymk. Consulte http://en.wikipedia.org/wiki/ISO/IEC_8859-1 para obtener una lista de scripts, y de hecho * caracteres * individuales, sí admite. –

+0

@qwertymk: Obviamente [no] (http://dev.mysql.com/doc/refman/5.5/en/charset-we-sets.html), se llama juego de caracteres de Europa occidental. – Jon

1

Las codificaciones de longitud fija como latin-1 son siempre más eficientes en términos de consumo de CPU.

Si se sabe que el conjunto de tokens en un conjunto de caracteres de longitud fija es suficiente para su propósito, y su propósito implica un procesamiento de cadena pesado e intenso, con muchas cosas LENGTH() y SUBSTR(), esa podría ser una buena razón para no usar codificaciones como UTF-8.

Ah, y por cierto. No confunda, como parece hacer, entre un conjunto de caracteres y una codificación . Un conjunto de caracteres es un conjunto definido de glifos grabables. El mismo conjunto de caracteres puede tener múltiples codificaciones distintas. Las diversas versiones del estándar Unicode constituyen un juego de caracteres. Cada uno de ellos puede estar sujeto a la codificación UTF-8, UTF-16 y "UTF-32" (no es un nombre oficial, sino que se refiere a la idea de utilizar cuatro bytes completos para cualquier carácter), y los dos últimos pueden cada uno vienen en HOB-first o HOB-last flavor.

15

Ventajas: UTF8

  1. soporta la mayoría de idiomas, incluyendo idiomas RTL como el hebreo.

  2. No se necesita traducción al importar/exportar datos a componentes compatibles con UTF8 (JavaScript, Java, etc.).

Desventajas: UTF8

  1. caracteres no ASCII se necesitará más tiempo para codificar y decodificar, debido a su esquema de codificación más compleja.

  2. Los caracteres no ASCII ocuparán más espacio ya que se pueden almacenar utilizando más de 1 byte (los caracteres no están en los primeros 127 caracteres de los caracteres ASCII configurados). Un campo CHAR(10) o VARCHAR(10) puede necesitar hasta 30 bytes para almacenar algunos caracteres UTF8.

  3. intercalaciones distintas de utf8_bin será más lento que el orden de clasificación no se asignan directamente a la orden de codificación de caracteres), y requerirán traducción en algunos procedimientos almacenados (por defecto a las variables utf8_general_ci cotejo).

  4. Si necesita JOIN campos UTF8 y no UTF8, MySQL impondrá un impacto en el rendimiento GRAVES. Lo que serían consultas por debajo del segundo podría tomar minutos si los campos unidos son conjuntos de caracteres diferentes/intercalaciones.

En pocas palabras:

Si no es necesario para apoyar las lenguas no Latin1, quieren conseguir el máximo rendimiento, o ya tiene tablas usando latin1, elegir latin1.

De lo contrario, elija UTF8.

+1

La afirmación "Es posible que necesite aumentar las longitudes de su campo' CHAR' para permitir el espacio adicional, ya que un 'VARCHAR (10)' solo puede almacenar cinco o menos caracteres de datos UTF8. " (en Desventaja 1) es incorrecto. El tamaño de la columna refleja la cantidad máxima de caracteres permitidos, no el tamaño de almacenamiento (ver http://dev.mysql.com/doc/refman/5.6/en/storage-requirements.html). –

+0

meden: tienes toda la razón. He actualizado mi respuesta para reflejar este hecho. Lo siento por el error. –

+0

¿qué hay de ASCII? en lugar de latín –

2

@Ross Smith II, el punto 4 vale oro, lo que significa que la inconsistencia entre las columnas puede ser peligrosa.

para añadir valor a las ya buenas respuestas, aquí es una pequeña prueba de rendimiento sobre la diferencia entre los conjuntos de caracteres:

Un moderno 2013 del servidor, el uso real de mesa con 20000 filas, sin índice en la columna en cuestión.

SELECCIONE 4 DE subscribers DONDE 1 PEDIDO POR time_utc_str; (4 es destructor de caché)

  • varchar (20) conjunto de caracteres COTEJO latin1 latin1_bin: 15 ms
  • varbinary (20): 17ms
  • utf8_bin: 20 ms
  • utf8_general_ci: 23 ms

Para cadenas simples como fechas numéricas, mi decisión sería, cuando se trata de rendimiento, usar utf8_bin (CHARACTER SET utf8 COLLATE utf8_bin). Esto evitaría cualquier efecto adverso con otro código que espera que los conjuntos de datos sean utf8 mientras siguen siendo de tipo binario.