mysql - type - ¿Por qué no especificar cada VARCHAR como VARCHAR(65535)?
mysql blob size (5)
De los documents - Tabla de conteo de columnas y límites de tamaño de fila:
Cada tabla (independientemente del motor de almacenamiento) tiene un tamaño máximo de fila de 65,535 bytes. Los motores de almacenamiento pueden imponer restricciones adicionales a este límite, reduciendo el tamaño máximo efectivo de la fila.
El tamaño máximo de la fila restringe el número (y posiblemente el tamaño) de las columnas porque la longitud total de todas las columnas no puede exceder este tamaño. Por ejemplo, los caracteres utf8 requieren hasta tres bytes por carácter, por lo que para una columna CHARFTER SET utf8 CHAR (255), el servidor debe asignar 255 × 3 = 765 bytes por valor. En consecuencia, una tabla no puede contener más de 65,535 / 765 = 85 columnas.
El almacenamiento para columnas de longitud variable incluye bytes de longitud, que se evalúan según el tamaño de la fila. Por ejemplo, una columna VARCHAR (255) CHARACTER SET utf8 toma dos bytes para almacenar la longitud del valor, por lo que cada valor puede tomar hasta 767 bytes.
Por lo tanto, la definición de una sola VARCHAR(65535) , lo limita efectivamente a una sola columna en la fila (asumiendo que la ha llenado).
Todo esto aparte del hecho de que un tamaño tan grande es completamente incorrecto para algunos tipos de datos: si tiene una columna de número de teléfono que puede contener números locales e internacionales, puede elegir usar un campo VARCHAR para hacerlo, pero configurándolo a cualquier cosa mayor de 20 puede no tener sentido (estoy siendo generoso).
Vea esta respuesta de Bill Karwin, que también indica posibles penalizaciones de rendimiento si las tablas temporales se generan con campos VARCHAR innecesariamente largos (relacionados con la conversión de dichos campos a CHAR y viceversa, consulte la publicación para obtener más información).
Dado que los requisitos de almacenamiento para un campo Varchar se basan en la longitud real de la cadena ingresada, ¿cuál sería el inconveniente de especificar cada campo Varchar como máximo posible: Varchar (65535)? Bueno, aparte de 1 byte extra para campos máx.> 255 caracteres?
[Requerimientos de almacenamiento para cadenas de longitud L: L + 1 bytes si los valores de columna requieren de 0 a 255 bytes, L + 2 bytes si los valores pueden requerir más de 255 bytes]
¡Gracias!
Por ejemplo, el motor MEMORY en MySQL no soporta muy bien los campos VARCHAR. El motor reservará para cada fila la cantidad máxima de bytes, no la longitud realmente utilizada. Entonces, si define una tabla con una sola columna VARCHAR (1000), tendrá un uso de memoria de 1000 * 3 bytes por cada fila que agregue, incluso si son cadenas vacías.
Una posible razón sería mejorar la compatibilidad con otras aplicaciones. Por ejemplo, si tuvieras una aplicación que usara un campo "product_no" que tuviera 100 caracteres de tiempo, y quisieras interactuar con una aplicación que usara un campo similar como "model_no" que tuviera 40 caracteres, sería una molestia. Cualquier product_nos en su aplicación que tuviera más de 40 caracteres se truncaría y tendría que encontrar alguna forma de traducirlos entre las aplicaciones.
Una razón es que el tamaño del campo es una verificación de los datos ingresados. ¿Realmente quieres que alguien ingrese un número de teléfono de 1000 caracteres? Tener un campo demasiado grande es una forma de garantizar que la basura se ingresará en su base de datos. Tendrá números de teléfono que dicen cosas como (ejemplo no tomado al azar):
"Solo habla con la gran rubia en la recepción"
en lugar de un número de teléfono real o un campo de correo electrónico que contenga notas sobre el cliente porque no tienen un campo de notas? Eso no funciona tan bien cuando intentas enviarle un correo electrónico.
Las tablas anchas pueden crear problemas propios en las bases de datos, ya que puede encontrarse con límites de registros inesperados (puede diseñar una tabla para que sea más ancha de lo que realmente se puede almacenar en un registro, a veces esto causa fallas en las inserciones) y problemas de rendimiento como datos se separa a través de las páginas de datos. Sé que puede tener eso de tablas amplias en SQL Server y no me sorprendería si mysql se encuentra con problemas similares. Sin embargo, un experto en mysql tendrá que abordar esto realmente. La indexación también puede ser un problema con campos amplios. El motor de la base de datos puede estar menos inclinado a pensar que el índice es útil. Una vez más, no estoy seguro de si mysql tendría este problema, pero es algo para investigar. Sé que estos son problemas con el uso del tamaño de campo máximo para todo en SQL Server, mysql puede tener estos problemas u otros que SQL Server no tiene.
Creo que las longitudes de las columnas varchar no son solo de almacenamiento. También se trata de datos semánticos.
IE que especifica una columna de name como varchar(100) significa que los nombres almacenados en su sistema no deben tener más de 100 caracteres.
En el lado de almacenamiento de las cosas, deberían ser iguales. Aunque, las estimaciones de tamaño de fila serían más precisas con una longitud específica en columnas varchar que sin ellas (sin la necesidad de un sistema de recopilación de estadísticas que mantenga las distribuciones de datos en tamaños varchar ).