mysql - entre - varchar max length
¿Hay desventajas al usar un varchar genérico(255) para todos los campos basados en texto? (7)
Tengo una tabla de contacts que contiene campos como postcode , first name , last name , town , country , phone number , etc., todos ellos definidos como VARCHAR(255) , aunque ninguno de estos campos se acercará a tener 255 caracteres . (Si te estás preguntando, es así porque las migraciones de Ruby on Rails mapean los campos String a VARCHAR(255) de forma predeterminada y nunca me preocupé por anularlo).
Como VARCHAR solo almacenará el número de caracteres reales del campo (junto con la longitud del campo), ¿hay alguna ventaja distintiva (de rendimiento o de otro tipo) para usar, por ejemplo, VARCHAR(16) sobre VARCHAR(255) ?
Además, la mayoría de estos campos tienen índices en ellos. ¿Un tamaño de VARCHAR más grande en el campo afecta el tamaño o el rendimiento del índice?
FYI estoy usando MySQL 5.
Además de las consideraciones de tamaño y rendimiento de establecer el tamaño de un varchar (y posiblemente más importante, ya que el almacenamiento y el procesamiento se abaratan cada segundo), la desventaja de utilizar varchar (255) "solo porque" es una integridad de datos reducida.
La definición de límites máximos para cadenas es una buena acción para evitar que cadenas más largas de lo esperado ingresen al RDBMS y causen desbordamientos de búfer o excepciones / errores más adelante al recuperar y analizar valores de la base de datos que son más largos (más bytes) de lo esperado.
Por ejemplo, si tiene un campo que acepta cadenas de dos caracteres para las abreviaturas de países, entonces no hay razón concebible para esperar que los usuarios (en este contexto, los programadores) ingresen los nombres completos de los países. Como no desea que entren en "Antigua y Barbuda" (AG) o "Islas Heard Island y McDonald" (HM), no lo permite en la capa de la base de datos. Además, es probable que algunos programadores aún no hayan RTFM la documentación de diseño ( que seguramente existe ) para saber que no deben hacer esto.
Establezca el campo para aceptar dos caracteres y deje que el RDBMS se encargue de él (ya sea de forma elegante truncando o desvergonzadamente rechazando su SQL con un error).
Ejemplos de datos reales que no tienen ninguna razón para exceder una cierta duración:
- Los códigos postales canadienses tienen el formato A1A1A1 y siempre tienen 6 caracteres de longitud, incluso para Santa Claus (6 caracteres excluyen el espacio que se puede especificar para la legibilidad).
- direcciones de correo electrónico : hasta 64 bytes antes del @, hasta 255 bytes después. Nunca más, no sea que rompas Internet.
- Los números de teléfono de América del Norte no tienen más de 10 dígitos (excluyendo el código de país).
- Equipos que se ejecutan (versiones recientes de) Windows no puede tener nombres de computadora de más de 63 bytes , aunque no se recomiendan más de 15 y romperán su granja de servidores de Windows NT.
- Las abreviaturas estatales son 2 caracteres (como los códigos de país que se muestran arriba)
- Los números de seguimiento de UPS tienen una longitud de 18, 12, 11 o 9 caracteres. Los números de 18 caracteres comienzan con "1Z" y los números de 11 caracteres comienzan con "T", lo que te hace preguntarte cómo reparten todos esos paquetes si no conocen la diferencia entre letras y números.
Y así...
Tómese el tiempo para pensar en sus datos y sus límites. Si eres arquitecto, desarrollador o programador, es tu trabajo , después de todo.
Al usar varchar (n) en lugar de varchar (255) elimina el problema por el que los usuarios (usuarios finales, programadores, otros programas) ingresan inesperadamente datos largos que volverán a atormentar su código más adelante.
Y no dije que tampoco debiera implementar esta restricción en el código de lógica de negocios utilizado por su aplicación.
En almacenamiento, VARCHAR(255) es lo suficientemente inteligente como para almacenar solo la longitud que necesita en una fila determinada, a diferencia de CHAR(255) que siempre almacenaría 255 caracteres.
Pero ya que etiquetó esta pregunta con MySQL, mencionaré un consejo específico de MySQL: cuando las filas se copian de la capa del motor de almacenamiento a la capa SQL, los campos VARCHAR se convierten a CHAR para obtener la ventaja de trabajar con filas de ancho fijo . Por lo tanto, las cadenas en la memoria se rellenan hasta la longitud máxima de su columna VARCHAR declarada.
Cuando su consulta genera implícitamente una tabla temporal, por ejemplo mientras ordena o GROUP BY , puede usar mucha memoria. Si usa muchos campos VARCHAR(255) para datos que no necesitan ser tan largos, esto puede hacer que la tabla temporal sea muy grande.
También puede desear saber que este comportamiento de "relleno" significa que una cadena declarada con el conjunto de caracteres utf8 rellena hasta tres bytes por carácter, incluso para las cadenas que almacena con contenido de un solo byte (por ejemplo, caracteres ascii o latin1). Y asimismo, el juego de caracteres utf8mb4 hace que la cadena rellene cuatro bytes por carácter en la memoria.
Así que un VARCHAR(255) en utf8 que almacena una cadena corta como "Sin opinión" toma 11 bytes en el disco (diez caracteres de caracteres inferiores, más un byte de longitud) pero requiere 765 bytes en memoria, y por lo tanto en tablas temporales o ordenadas resultados.
Ayudé a los usuarios de MySQL que sin saberlo crearon tablas temporales de 1.5GB con frecuencia y llenaron su espacio en disco. Tenían muchas columnas VARCHAR(255) que en la práctica almacenaban cadenas muy cortas.
Lo mejor es definir la columna en función del tipo de datos que desea almacenar. Tiene beneficios para aplicar restricciones relacionadas con las aplicaciones, como otros mencionaron. Pero tiene los beneficios físicos para evitar el desperdicio de memoria que describí anteriormente.
Es difícil saber cuál es la dirección postal más larga, por supuesto, y es por eso que muchas personas eligen un VARCHAR largo que es ciertamente más largo que cualquier dirección. Y 255 es habitual porque es la longitud máxima de un VARCHAR cuya longitud puede codificarse con un byte. También fue la longitud máxima de VARCHAR en MySQL anterior a 5.0.
En mi experiencia, si permites un tipo de datos de 255 caracteres, algún usuario estúpido (o algún tester experimentado) realmente lo completará.
Luego tiene todo tipo de problemas, incluido el espacio que permite para esos campos en los informes y las visualizaciones en pantalla en su aplicación. Sin mencionar la posibilidad de exceder el límite por fila para los datos en su base de datos (si tenía más de unos de estos 255 campos de caracteres).
Es mucho más fácil elegir un límite razonable al principio, luego aplicarlo a través de la aplicación y la base de datos.
En un contexto mysql puede ser importante cuando se trabaja con índices en dichas columnas varchar, ya que mysql tiene un máximo. límite de 767bytes por fila de índice.
Esto significa que al agregar un índice en varias columnas varchar 255 puede llegar a este límite bastante rápido / incluso más rápido en las columnas utf8 o utf8mb4 como se señala en las respuestas anteriores
Es una buena práctica asignar solo un poco más de lo que necesita. Los números de teléfono nunca serían tan grandes.
Una de las razones es que a menos que valide contra entradas grandes, sin duda alguien usará todo lo que hay. Entonces podrías quedarte sin espacio en tu fila. No estoy seguro del límite de MySQL, pero 8060 es el máximo de filas en MS SQL.
Un valor por defecto más normal sería 50 imho, y luego aumentar donde lo demuestre.
Estoy contigo. La atención extrema al detalle es un dolor en el cuello y tiene un valor limitado.
Érase una vez, el disco era un bien preciado y solíamos sudar balas para optimizarlo. El precio del almacenamiento ha disminuido en un factor de 1.000, lo que hace que el tiempo dedicado a exprimir cada byte sea menos valioso.
Si usa solo campos CHAR, puede obtener filas de longitud fija. Esto puede ahorrar algo de disco real-restate si seleccionó tamaños exactos para los campos. Es posible que obtenga datos más densamente empaquetados (menos E / S para escaneos de tabla) y actualizaciones más rápidas (más fácil de localizar espacios abiertos en un bloque para actualizaciones e inserciones).
Sin embargo, si sobreestima sus tamaños, o si los tamaños de sus datos reales son variables, terminará desperdiciando espacio con los campos CHAR. Los datos terminarán siendo menos densamente empaquetados (lo que generará más E / S para grandes recuperaciones).
En general, los beneficios de rendimiento de intentar poner un tamaño en campos variables son menores. Puede comparar fácilmente usando VARCHAR (255) en comparación con CHAR (x) para ver si puede medir la diferencia.
Sin embargo, a veces, necesito proporcionar una pista "pequeña", "mediana", "grande". Entonces uso 16, 64 y 255 para los tamaños.
Hoy en día, no puedo imaginar que realmente importe más.
Existe una sobrecarga computacional para usar campos de longitud variable, pero con los excesos de las CPU actuales, ni siquiera vale la pena considerarlo. El sistema de E / S es tan lento que hace que los costos computacionales para manejar los varcars sean prácticamente inexistentes. De hecho, el precio de un varchar computacionalmente es probablemente una ganancia neta sobre la cantidad de espacio de disco ahorrado mediante el uso de campos de longitud variable en campos de longitud fija. Lo más probable es que tenga una mayor densidad de fila.
Ahora, la complejidad de los campos varchar es que no puede ubicar fácilmente un registro a través de su número de registro. Cuando tiene un tamaño de fila de longitud fija (con campos de longitud fija), es trivial calcular el bloque de disco al que apunta una identificación de fila. Con un tamaño de filas de longitud variable, ese tipo de letra sale por la ventana.
Por lo tanto, ahora necesita mantener algún tipo de índice de número de registro, como cualquier otra clave principal, O necesita crear un identificador de fila robusto que codifique los detalles (como el bloque, etc.) en el identificador. Sin embargo, si hace eso, la identificación debería ser recalculada si alguna vez la fila se mueve en el almacenamiento persistente. No es gran cosa, solo necesita volver a escribir todas las entradas de índice y asegurarse de que: a) nunca lo exponga al consumidor ob) nunca afirme que el número es confiable.
Pero dado que hoy tenemos campos varchar, el único valor de varchar (16) sobre varchar (255) es que el DB aplicará el límite de 16 caracteres en el varchar (16). Si se supone que el modelo de DB es realmente representativo del modelo de datos físicos, tener longitudes de campos puede ser valioso. Sin embargo, si es simplemente un "almacenamiento" en lugar de un "modelo Y almacenamiento", no hay necesidad alguna.
Entonces, simplemente necesita discernir entre un campo de texto que es indexable (tal varchar) contra algo que no es (como un campo de texto o CLOB). Los campos indexables tienden a tener un límite de tamaño para facilitar el índice, mientras que los campos CLOB no (dentro de lo razonable).