sql >> Base de Datos >  >> RDS >> Mysql

char vs varchar para el rendimiento en la base de datos de stock

En MyISAM, hay algunos beneficios al hacer registros de ancho fijo. VARCHAR es ancho variable. CHAR es de ancho fijo. Si sus filas solo tienen tipos de datos de ancho fijo, entonces toda la fila es de ancho fijo y MySQL obtiene cierta ventaja al calcular los requisitos de espacio y el desplazamiento de las filas en esa tabla. Dicho esto, la ventaja puede ser pequeña y apenas vale la pena una posible pequeña ganancia que se ve superada por otros costos (como la eficiencia de la memoria caché) de tener columnas CHAR acolchadas de ancho fijo donde VARCHAR se almacenaría de manera más compacta.

El punto de interrupción en el que se vuelve más eficiente depende de su aplicación, y esto no es algo que se pueda responder excepto si prueba ambas soluciones y usa la que funciona mejor para sus datos bajo el uso de su aplicación.

Con respecto a INT (7) frente a INT (11), esto es irrelevante para el almacenamiento o el rendimiento. Es un malentendido común que el argumento de MySQL para el tipo INT tenga algo que ver con el tamaño de los datos, no es así. El tipo de datos INT de MySQL siempre es de 32 bits. El argumento entre paréntesis se refiere a cuántos dígitos rellenar si muestra el valor con ZEROFILL. P.ej. INT(7) mostrará 0001234 donde INT(11) mostrará 00000001234. Pero este relleno solo ocurre cuando se muestra el valor, no durante el almacenamiento o el cálculo matemático.