¿Cuál es la diferencia entre VARCHAR y CHAR?

366

¿Cuál es la diferencia entre VARCHAR y CHAR en MySQL?

Estoy tratando de almacenar hash MD5.

Steven
fuente
15
El hash MD5 siempre tiene 32 caracteres. Por lo tanto, para maximizar su rendimiento, use CHAR (32) ya que CHAR tiene una longitud fija (consulte las respuestas a continuación para obtener más detalles sobre las diferencias entre CHAR y VARCHAR).
Augustin

Respuestas:

361

VARCHAR es de longitud variable.

CHAR Es de longitud fija.

Si su contenido tiene un tamaño fijo, obtendrá un mejor rendimiento con CHAR.

Consulte la página MySQL sobre los tipos CHAR y VARCHAR para obtener una explicación detallada (asegúrese de leer también los comentarios).

Luego.
fuente
51
@ Steven: cuando Anon. dice "su contenido tiene un tamaño fijo" significa que las filas de su tabla deben contener todos los campos de tamaño fijo. No obtiene ninguna mejora en el rendimiento si usa CHAR contra VARCHAR en un campo, pero la tabla contiene otros campos que son VARCHAR.
Marco Demaio
2
no char datatype agrega el rendimiento ... mientras se ejecuta la consulta sql generará un plan de ejecución. Suponga que hay 2 columnas charcol char (2000) y VarcharCol Varchar (2000). En el plan de ejecución, el tamaño de fila estimado para el tipo de columnas varchar podría estar subestimado. así lleva el derrame a temp db. Así que usar char es bueno para el rendimiento
vignesh
1
¿Cuál es el significado del valor en la parántesis de VARCHAR (n)?
Sivagami Nambi
@Marco Demaio, ¿sabes la razón detrás de esto?
Dehan de Croos
1
@ jdc91: para que el rendimiento aumente, toda la fila debe ser de ancho fijo. MySQL gana ventaja al calcular los requisitos de espacio y el desplazamiento de las filas en ese tipo de tabla.
Marco Demaio
225

CARBONIZARSE

  1. Se utiliza para almacenar el valor de la cadena de caracteres de longitud fija .
  2. El máximo no. El número de caracteres que puede contener el tipo de datos es de 255 caracteres .
  3. Es un 50% más rápido que VARCHAR.
  4. Utiliza asignación de memoria estática .

VARCHAR

  1. Se usa para almacenar datos alfanuméricos de longitud variable .
  2. El máximo que puede contener este tipo de datos es hasta
    • Pre-MySQL 5.0.3: 255 caracteres .
    • Post-MySQL 5.0.3: 65,535 caracteres compartidos para la fila.
  3. Es más lento que CHAR.
  4. Utiliza asignación de memoria dinámica .
simplePerson43
fuente
3
Estoy un poco sorprendido de que esta respuesta haya sido votada tan a menudo. La documentación de MySQL diceValues in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions.
DroidOS
2
sin mencionar que también puedes almacenar datos alfanuméricos en char
ninjabber
44
¿En qué se basa esto un 50% más rápido? ¿50% más rápido para hacer qué? ¿En que condiciones? ¿Y qué quiere decir con asignación de memoria estática vs dinámica en este contexto?
Martin Smith
44
@ MartinSmith, iba a preguntar lo mismo ... no creo que la información sea precisa. asktom.oracle.com/pls/asktom/…
Ozgur Bar
2
-1; las afirmaciones de rendimiento aquí son vagas y sin fundamento, la diferencia en la estrategia de asignación de memoria (y por qué es importante) no se concreta, y la afirmación de que varchar almacena "datos alfanuméricos" es un poco extraña; ¡Las columnas varchar ciertamente también pueden almacenar caracteres no alfanuméricos!
Mark Amery el
122

CHAR Vs VARCHAR

CHAR se usa para la variable de tamaño de longitud fija
VARCHAR se usa para la variable de tamaño de longitud variable.

P.ej

Create table temp
(City CHAR(10),
Street VARCHAR(10));

Insert into temp
values('Pune','Oxford');

select length(city), length(street) from temp;

La salida será

length(City)          Length(street)
10                    6

Conclusión: para usar el espacio de almacenamiento de manera eficiente, debe usar VARCHAR en lugar de CHAR si la longitud variable es variable

P Sharma
fuente
44
Ciudad = char (10), Calle = varchar (10), ciudad = Pune, calle = Oxford, longitud (ciudad) = 4, longitud (calle) = 6
abdulwadood
2
esta consulta (seleccionar longitud (ciudad), longitud (calle) desde temp) está dando el siguiente resultado en mysql 5.7 mysql> seleccionar longitud (ciudad), longitud (calle) desde temp; + -------------- + ---------------- + | longitud (ciudad) | longitud (calle) | + -------------- + ---------------- + | 4 | 6 | + -------------- + ---------------- + 1 fila en conjunto (0.00 seg)
Jasbeer Rawal
69

Una CHAR(x)columna solo puede tener exactamente x caracteres.
Una VARCHAR(x)columna puede tener hasta x caracteres.

Dado que sus hashes MD5 siempre serán del mismo tamaño, probablemente debería usar a CHAR.

Sin embargo, no deberías usar MD5 en primer lugar; ha conocido debilidades.
Use SHA2 en su lugar.
Si utiliza contraseñas hash, debe usar bcrypt.

SLaks
fuente
44
"Una columna CHAR (x) solo puede tener exactamente x caracteres". En realidad, puede agregar datos con menos de x caracteres, pero creo que quiso decir que siempre RESERVA 10 caracteres de memoria detrás de escena.
Dan W
13
No sabe por qué están almacenando hash md5, hay muchas, muchas razones válidas para usar md5 que no tienen nada que ver con la seguridad. Las colisiones no son comunes en absoluto y el algoritmo es más rápido que los más seguros.
John Hunt
1
Suponiendo que la columna CHAR (x) no imponga los caracteres x exactamente, ¿hay alguna razón para usarlo sobre VARCHAR (x) incluso para datos de tamaño fijo?
NeverEndingQueue
11

¿Cuál es la diferencia entre VARCHAR y CHAR en MySQL?

A las respuestas ya dadas, me gustaría agregar que en los sistemas OLTP o en sistemas con actualizaciones frecuentes considere usar CHARincluso para columnas de tamaño variable debido a la posible VARCHARfragmentación de la columna durante las actualizaciones.

Estoy tratando de almacenar hash MD5.

El hash MD5 no es la mejor opción si la seguridad realmente importa. Sin embargo, si va a utilizar cualquier función hash, considere BINARYescribir en su lugar (por ejemplo, MD5 producirá hash de 16 bytes, por BINARY(16)lo que sería suficiente en lugar de CHAR(32)32 caracteres que representan dígitos hexadecimales. Esto ahorraría más espacio y sería eficaz en el rendimiento).

Grygoriy Gonchar
fuente
Siguiendo esta línea de pensamiento, usaría CHAR para las identificaciones comerciales que están pensadas para facilitar la lectura frente a la eficiencia. Sin embargo, todavía usaría las claves principales de bigint.
Archimedes Trajano
9

Varchar corta los espacios finales si los caracteres ingresados ​​son más cortos que la longitud declarada, mientras que char no lo hará. Char rellenará espacios y siempre será la longitud de la longitud declarada. En términos de eficiencia, varchar es más experto, ya que recorta caracteres para permitir un mayor ajuste. Sin embargo, si conoce la longitud exacta de char, char se ejecutará con un poco más de velocidad.

usuario1445657
fuente
7

En la mayoría de los RDBMS de hoy, son sinónimos. Sin embargo, para aquellos sistemas que aún tienen una distinción, un campo CHAR se almacena como una columna de ancho fijo. Si lo define como CHAR (10), se escriben 10 caracteres en la tabla, donde se utiliza "relleno" (normalmente espacios) para completar cualquier espacio que los datos no consuman. Por ejemplo, guardar "bob" se guardaría como ("bob" +7 espacios). Una columna VARCHAR (carácter variable) está destinada a almacenar datos sin desperdiciar el espacio extra que hace una columna CHAR.

Como siempre, Wikipedia habla más fuerte.

mobiGeek
fuente
5

CHAR es un campo de longitud fija; VARCHAR es un campo de longitud variable. Si está almacenando cadenas con una longitud muy variable, como nombres, use un VARCHAR, si la longitud es siempre la misma, use un CHAR porque es un poco más eficiente en tamaño y también un poco más rápido.

Andrés
fuente
Si bien supongo que las afirmaciones sobre la velocidad y la eficiencia del almacenamiento aquí son ciertas, ninguna de ellas está justificada de ninguna manera (y es perfectamente plausible que sean falsas), lo que hace que esta respuesta no sea útil; simplemente repite lo que el lector probablemente ya hubiera esperado que fuera cierto, sin hacer nada para ayudarlo a confirmarlo.
Mark Amery el
1

CHAR es de longitud fija y VARCHAR es de longitud variable. CHAR siempre usa la misma cantidad de espacio de almacenamiento por entrada, mientras que VARCHAR solo usa la cantidad necesaria para almacenar el texto real.

Donnie DeBoer
fuente
1

El carácter es un tipo de datos de caracteres de longitud fija, el varchar es un tipo de datos de caracteres de longitud variable.

Como char es un tipo de datos de longitud fija, el tamaño de almacenamiento del valor de char es igual al tamaño máximo para esta columna. Como varchar es un tipo de datos de longitud variable, el tamaño de almacenamiento del valor varchar es la longitud real de los datos ingresados, no el tamaño máximo para esta columna.

Puede usar char cuando se espera que las entradas de datos en una columna sean del mismo tamaño. Puede usar varchar cuando se espera que las entradas de datos en una columna varíen considerablemente en tamaño.

Bob Minteer
fuente
0

según el libro MySQL de alto rendimiento :

VARCHAR almacena cadenas de caracteres de longitud variable y es el tipo de datos de cadena más común. Puede requerir menos espacio de almacenamiento que los tipos de longitud fija, porque usa solo el espacio que necesita (es decir, se usa menos espacio para almacenar valores más cortos). La excepción es una tabla MyISAM creada con ROW_FORMAT = FIXED, que utiliza una cantidad fija de espacio en el disco para cada fila y, por lo tanto, puede desperdiciar espacio. VARCHAR ayuda al rendimiento porque ahorra espacio.

CHAR tiene una longitud fija: MySQL siempre asigna suficiente espacio para el número especificado de caracteres. Al almacenar un valor CHAR, MySQL elimina los espacios finales. (Esto también era cierto para VARCHAR en MySQL 4.1 y versiones anteriores: CHAR y VAR CHAR eran lógicamente idénticos y solo diferían en el formato de almacenamiento). Los valores se rellenan con espacios según sea necesario para las comparaciones.

Alireza Rahmani Khalili
fuente
2
" VARCHAR ayuda al rendimiento porque ahorra espacio " Ahorra espacio, sí, pero ¿no afecta negativamente el rendimiento? VARCHARnecesita asignar memoria de forma dinámica cuando sea necesario, reduciendo así el rendimiento en lugar de CHAR, ¿verdad?
Spikatrix
@Spikatrix depende. Si los valores de VARCHAR a menudo son pequeños pero podrían tener hasta N bytes, la asignación dinámica podría ahorrar una cantidad significativa de espacio y E / S, que es más eficiente para muchos datos. Los valores CHAR que son aproximadamente iguales en longitud serían más efectivos. Las lecturas frente a las escrituras también probablemente marcan la diferencia.
Andrew
-4

Char tiene una longitud fija (admite 2000 caracteres), es un carácter de tipo de datos

Varchar tiene una longitud variable (admite 4000 caracteres)

Amandeep
fuente
-1; Estos números no son correctos para MySQL. (¿Creo que podrían ser para Oracle?)
Mark Amery
-5

Char o varchar- se usa para ingresar datos de texto donde la longitud se puede indicar entre paréntesis Ej. Nombre char (20)

Amy
fuente
Esto no aborda la pregunta original. OP pregunta las diferencias prácticas entre los tipos, no la sintaxis y el propósito de los tipos. También (y )son paréntesis, no paréntesis.
2mac
@ 2mac su oración final solo es cierta para el inglés americano; en Gran Bretaña llamamos (y )paréntesis, y muchos británicos probablemente ni siquiera se dan cuenta de que hay dialectos del inglés en los que la palabra "paréntesis" puede referirse a un signo de puntuación. Hay un fuerte argumento para preferir los "paréntesis" a los "paréntesis", es probable que, en conjunto, sea la opción máximamente clara cuando se dirige a una audiencia internacional de programadores, pero es un caso más complicado que "paréntesis" simplemente estar equivocado.
Mark Amery
-11

CHAR:

  • Admite caracteres y números.
  • Soporta 2000 caracteres.
  • Longitud fija.

VARCHAR:

  • Admite caracteres y números.
  • Admite 4000 caracteres.
  • Longitud variable.

algún comentario......!!!!

YRSREDDY
fuente