¿Tiene algún sentido usar CHAR si tiene un VARCHAR en la misma tabla?

Question

Acabo de leer la respuesta aceptada de this question, que me dejó con esta pregunta.

Aquí es una cita de esa respuesta:

"Pero ya ha etiquetado esta pregunta con MySQL, voy a mencionar una punta específica de MySQL: cuando su consulta genera implícitamente una tabla temporal, por ejemplo, mientras que la clasificación o GROUP BY , VARCHAR campos se convierten a CHAR para obtener la ventaja de trabajar con filas de ancho fijo. Si usa muchos campos VARCHAR(255) para datos que no necesitan ser tan largos, esto puede hacer que la tabla temporal sea muy grande. "

Según tengo entendido, la ventaja de CHAR es que se obtienen filas de ancho fijo, por lo que no se descompone un VARCHAR en la misma mesa? ¿Hay alguna ventaja de usar CHAR cuando tiene un VARCHAR en la misma tabla?

---

He aquí un ejemplo:

tabla con CHAR:

CREATE TABLE address (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT, 
    street VARCHAR(100) NOT NULL, 
    postcode CHAR(8) NOT NULL, 
    PRIMARY KEY (id) 
); 

Tabla sin CHAR:

CREATE TABLE address (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT, 
    street VARCHAR(100) NOT NULL, 
    postcode VARCHAR(8) NOT NULL, 
    PRIMARY KEY (id) 
); 

¿La mesa con CHAR realizar ninguna mejor que la mesa sin CHAR , y si es así, en qué situaciones?

Answer 1

"VARCHAR" básicamente establece una longitud máxima para el campo y solo almacena los datos que se ingresan en ella, ahorrando espacio. El tipo "CHAR" tiene una longitud fija, por lo que si establece "CHAR(100)", se utilizará un espacio de 100 caracteres, independientemente de su contenido.

La única vez que obtendrá una ventaja de velocidad es si no tiene campos de longitud variable en su registro ("VARCHAR", "TEXT", etc.). Puede notar que internamente todos sus campos "CHAR" se cambian a "VARCHAR" tan pronto como MySQL agrega un tipo de campo de longitud variable.

También "CHAR" es menos eficiente desde el punto de vista del almacenamiento espacial, pero es más eficiente para buscar y agregar. Es más rápido porque la base de datos solo tiene que leer un valor de compensación para obtener un registro en lugar de leer partes hasta que encuentre el final de un registro. Y los registros de longitud fija minimizarán la fragmentación, ya que el espacio de registro eliminado puede reutilizarse para nuevos registros.

Espero que ayude.