Optimizar Una Consulta

Cuidado al diseñar el esquema

Antes de hacer consultas, lo primero que deberías hacer es diseñar el esquema y quizá es uno de los pasos más importantes si la aplicación. La memoria necesaria para una tabla es el número de entradas por el tamaño de una fila ( de perogrullo )  por lo que las tablas deben tener un tamaño aceptable. Es lógico que un campo nombre sea varchar pero, ¿qué pasa con un código postal que solo va a tener 5 caracteres… siempre?

Veamos lo que pasa internamente:

Valor   CHAR (5)       Almacenamiento requerido   VARCHAR (5)           Almacenamiento requerido

''          ' '         5 bytes            ''          1 byte

‘ab’      'ab '     5 bytes            'ab'      3 bytes

'abcde' 'abcde' 5 bytes            'abcde' 6 bytes

Como ves, a tamaño completo, no tiene mucho sentido guardar un varchar de 5 caracteres teniendo en cuenta que, si siempre va a ocupar lo máximo, ocupará más que si fuera un char.

Particiona las tablas

Es bastante común tener tablas de las que solo seleccionemos algunas columnas en concreto con asiduidad. Imagina por ejemplo la tabla de un usuario en la que podemos llegar a guardar un montón de información como su fecha de nacimiento, departamento al que pertenece, etc. Pero habitualmente accederás a su nombre de usuario, correo, contraseña y poco más. Para esos casos, es buena idea particionar la tabla:

CREATE TABLE usuarios {

    id INT unsigned not null auto_increment,

    usuario VARCHAR(20) not null,

    password VARCHAR(40) not null,

    email VARCHAR(40),

    PRIMARY KEY(id)

}

CREATE TABLE datos_usuario {

    id_usuario INT unsigned not null,

    id_departamento INT unsigned,

    fecha_nacimiento DATE,

    dni CHAR(9),

    PRIMARY KEY (id_usuario)

}

Los datos que usamos frecuentemente los mantenemos en una tabla mientras que los que usamos con menos frecuencia los dejamos en otra, esto hará que la tabla menos frecuente ocupe menos memoria.

Encadena SELECT o usa JOIN pero no ambos

Aparte de que son menos mantenibles y legibles, tienen un alto impacto en cuanto a recursos usados. Por regla general además, es recomendable no usar SELECTs anidados y usar únicamente JOINs ya que el rendimiento es casi siempre mejor. Recuerda que, por regla general, puedes convertir un SELECT anidado en un JOIN fácilmente:

SELECT usuario

FROM usuarios

WHERE id IN (

    SELECT id

    FROM datos_usuario

    WHERE departamento = 1

)

Ahora con JOINs

SELECT usuarios.usuario

FROM usuarios

INNER JOIN datos_usuario ON usuarios.id = datos_usuario.id

WHERE datos_usuario.departamento = 1;

Este es un error bastante común para los iniciados al SQL ya que la primera consulta es más “natural” para el programador.