mysql - tipo - Mejores prácticas para la longitud de la columna varchar de SQL
varchar max (7)
Agregando a la respuesta de a_horse_with_no_name, puede encontrar lo siguiente de interés ...
no hace ninguna diferencia si declara una columna como VARCHAR (100) o VACHAR (500).
-- try to create a table with max varchar length
drop table if exists foo;
create table foo(name varchar(65535) not null)engine=innodb;
MySQL Database Error: Row size too large.
-- try to create a table with max varchar length - 2 bytes for the length
drop table if exists foo;
create table foo(name varchar(65533) not null)engine=innodb;
Executed Successfully
-- try to create a table with max varchar length with nullable field
drop table if exists foo;
create table foo(name varchar(65533))engine=innodb;
MySQL Database Error: Row size too large.
-- try to create a table with max varchar length with nullable field
drop table if exists foo;
create table foo(name varchar(65532))engine=innodb;
Executed Successfully
No olvide el (los) byte (s) de longitud y el byte que puede contener nulos así que:
name varchar(100) not null será de 1 byte (longitud) + hasta 100 caracteres (latin1)
name varchar(500) not null será de 2 bytes (longitud) + hasta 500 caracteres (latin1)
name varchar(65533) not null será de 2 bytes (longitud) + hasta 65533 caracteres (latin1)
name varchar(65532) tendrá 2 bytes (longitud) + hasta 65532 caracteres (latin1) + 1 byte nulo
Espero que esto ayude :)
Cada vez que se configura una nueva tabla SQL o se agrega una nueva columna varchar a una tabla existente, me pregunto una cosa: cuál es el mejor valor para la length .
Entonces, digamos, usted tiene una columna llamada name de tipo varchar . Por lo tanto, tienes que elegir la longitud. No puedo pensar en un nombre> 20 caracteres, pero nunca lo sabrás. Pero en lugar de usar 20, siempre redondeo al siguiente número 2 ^ n. En este caso, elegiría 32 como la longitud. Hago eso porque, desde el punto de vista de un científico informático, un número 2 ^ n se ve más even que otros números y supongo que la arquitectura que se encuentra debajo puede manejar esos números un poco mejor que otros.
Por otro lado, el servidor MSSQL, por ejemplo, establece el valor de longitud predeterminado en 50, cuando elige crear una columna varchar. Eso me hace pensar en ello. ¿Por qué 50? ¿Es solo un número aleatorio, o se basa en la longitud promedio de la columna, o qué?
También podría ser, o probablemente es, que diferentes implementaciones de servidores SQL (como MySQL, MSSQL, Postgres, ...) tengan diferentes valores de mejor longitud de columna.
Cada vez que configuro una nueva tabla SQL, siento que 2 ^ n es más "par" ... pero para resumir las respuestas aquí, no hay un impacto significativo en el espacio de almacenamiento simplemente definiendo varchar (2 ^ n) o incluso varchar (MAX).
Dicho esto, aún debe anticipar las posibles implicaciones en el almacenamiento y el rendimiento al establecer un límite alto varchar (). Por ejemplo, supongamos que crea una columna varchar (MAX) para contener descripciones de productos con indexación de texto completo. Si el 99% de las descripciones solo tienen 500 caracteres, y de repente, obtiene a alguien que reemplaza dichas descripciones con artículos de wikipedia, puede que observe impactos significativos no anticipados de almacenamiento y rendimiento.
Otra cosa a considerar de Bill Karwin :
Hay un posible impacto en el rendimiento: en MySQL, las tablas temporales y las tablas de MEMORIA almacenan una columna VARCHAR como una columna de longitud fija, rellenada hasta su longitud máxima. Si diseña columnas VARCHAR mucho más grandes que el tamaño más grande que necesita, consumirá más memoria de la que debe. Esto afecta la eficiencia del caché, la velocidad de clasificación, etc.
Básicamente, solo se presentan restricciones comerciales y errores razonables en un tamaño ligeramente mayor. Como señaló @onedaywhen, los nombres de familia en el Reino Unido suelen tener entre 1 y 35 caracteres. Si decides convertirlo en varchar (64), realmente no vas a dañar nada ... a menos que estés guardando el apellido de este tipo que se dice que tiene hasta 666 caracteres. En ese caso, tal vez varchar (1028) tiene más sentido.
Y en caso de que sea útil, esto es lo que puede verse varchar 2 ^ 5 a 2 ^ 10 si está lleno:
varchar(32) Lorem ipsum dolor sit amet amet.
varchar(64) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
varchar(128) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
varchar(256) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
velit metus, sit amet tristique purus condimentum eleifend. Quis
que mollis magna vel massa malesuada bibendum. Proinde tincidunt
varchar(512) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
velit metus, sit amet tristique purus condimentum eleifend. Quis
que mollis magna vel massa malesuada bibendum. Proinde tincidunt
dolor tellus, sit amet porta neque varius vitae. Seduse molestie
lacus id lacinia tempus. Vestibulum accumsan facilisis lorem, et
mollis diam pretium gravida. In facilisis vitae tortor id vulput
ate. Proin ornare arcu in sollicitudin pharetra. Crasti molestie
varchar(1024) Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
velit metus, sit amet tristique purus condimentum eleifend. Quis
que mollis magna vel massa malesuada bibendum. Proinde tincidunt
dolor tellus, sit amet porta neque varius vitae. Seduse molestie
lacus id lacinia tempus. Vestibulum accumsan facilisis lorem, et
mollis diam pretium gravida. In facilisis vitae tortor id vulput
ate. Proin ornare arcu in sollicitudin pharetra. Crasti molestie
dapibus leo lobortis eleifend. Vivamus vitae diam turpis. Vivamu
nec tristique magna, vel tincidunt diam. Maecenas elementum semi
quam. In ut est porttitor, sagittis nulla id, fermentum turpist.
Curabitur pretium nibh a imperdiet cursus. Sed at vulputate este
proin fermentum pretium justo, ac malesuada eros et Pellentesque
vulputate hendrerit molestie. Aenean imperdiet a enim at finibus
fusce ut ullamcorper risus, a cursus massa. Nunc non dapibus vel
Lorem ipsum dolor sit amet, consectetur Praesent ut ultrices sit
El mejor valor es el correcto para los datos tal como se define en el dominio subyacente.
Para algunos dominios, VARCHAR(10) es adecuado para el atributo Name , para otros dominios VARCHAR(255) podría ser la mejor opción.
Ningún DBMS que conozco tiene alguna "optimización" que haga que un VARCHAR con una longitud de 2^n tenga un mejor rendimiento que una con una longitud max que no sea una potencia de 2.
Creo que las primeras versiones de SQL Server en realidad trataron un VARCHAR con una longitud 255 diferente a una con una longitud máxima más alta. No sé si este sigue siendo el caso.
Para casi todos los DBMS, el almacenamiento real requerido solo está determinado por la cantidad de caracteres que ingresa, no por la longitud max que define. Por lo tanto, desde el punto de vista del almacenamiento (y muy probablemente también el de rendimiento), no hace ninguna diferencia si declara una columna como VARCHAR(100) o VARCHAR(500) .
Debería ver la longitud max provista para una columna VARCHAR como un tipo de restricción (o regla de negocios) en lugar de una cosa técnica / física.
Para PostgreSQL, la mejor configuración es usar text sin restricción de longitud y una CHECK CONSTRAINT que limite la cantidad de caracteres a lo que requiera su empresa.
Si ese requisito cambia, la modificación de la restricción de verificación es mucho más rápida que la modificación de la tabla (porque no es necesario volver a escribir la tabla)
Lo mismo se puede aplicar para Oracle y otros, aunque en Oracle sería VARCHAR(4000) lugar de text .
No sé si hay una diferencia de almacenamiento físico entre VARCHAR(max) y, por ejemplo, VARCHAR(500) en SQL Server. Pero al parecer hay un impacto en el rendimiento cuando se utiliza varchar(max) en comparación con varchar(8000) .
Ver este enlace (publicado por Erwin Brandstetter como comentario)
Editar 2013-09-22
Respecto al comentario de bigown:
En las versiones de Postgres anteriores a 9.2 (que no estaban disponibles cuando escribí la respuesta inicial), un cambio en la definición de columna reescribió la tabla completa, consulte, por ejemplo, here . Dado que 9.2 ya no es el caso y una prueba rápida confirmó que aumentar el tamaño de columna para una tabla con 1.2 millones de filas en realidad solo tomó 0.5 segundos.
Para Oracle, esto también parece ser cierto, a juzgar por el tiempo que lleva alterar la columna varchar una gran mesa. Pero no pude encontrar ninguna referencia para eso.
Para MySQL, el manual dice " En la mayoría de los casos, ALTER TABLE hace una copia temporal de la tabla original ". Y mis propias pruebas confirman que: la ejecución de ALTER TABLE en una tabla con 1.2 millones de filas (lo mismo que en mi prueba con Postgres) para aumentar el tamaño de una columna tomó 1.5 minutos. Sin embargo, en MySQL no puede usar la "solución alternativa" para usar una restricción de verificación para limitar el número de caracteres en una columna.
Para SQL Server no pude encontrar una declaración clara sobre esto, pero el tiempo de ejecución para aumentar el tamaño de una columna varchar (nuevamente la tabla de 1.2 millones de filas de arriba) indica que no se realiza ninguna reescritura.
Editar 2017-01-24
Parece que estaba (al menos parcialmente) equivocado acerca de SQL Server. Vea esta respuesta de Aaron Bertrand que muestra que la longitud declarada de las columnas nvarchar o varchar hace una gran diferencia para el rendimiento.
No he comprobado esto últimamente, pero sé en el pasado con Oracle que el controlador JDBC reservaría una porción de memoria durante la ejecución de la consulta para mantener el conjunto de resultados que regresa. El tamaño del fragmento de memoria depende de las definiciones de columna y del tamaño de recuperación. Por lo tanto, la longitud de las columnas varchar2 afecta la cantidad de memoria reservada. Esto me causó serios problemas de rendimiento hace años, ya que siempre usamos varchar2 (4000) (el máximo en ese momento) y la recolección de basura era mucho menos eficiente de lo que es hoy.
Siempre consulte con su experto de dominio de negocios. Si ese eres tú, busca un estándar de la industria. Si, por ejemplo, el dominio en cuestión es el apellido de una persona física (apellido), entonces, para una empresa del Reino Unido, acudiría al catálogo de estándares de datos de Govtalk del Reino Unido para obtener información de la persona y descubrir que un apellido tendrá entre 1 y 35 caracteres. .
VARCHAR(255) y VARCHAR(2) ocupan exactamente la misma cantidad de espacio en el disco! Entonces, la única razón para limitarlo es si tiene una necesidad específica de que sea más pequeño. De lo contrario hazlos todos los 255.
Específicamente, al hacer la clasificación, las columnas más grandes ocupan más espacio, por lo que si eso afecta el rendimiento, entonces debe preocuparse por eso y hacerlas más pequeñas. Pero si solo seleccionas 1 fila de esa tabla, entonces puedes hacerlas todas las 255 y no importará.