Query muuuy lento

[datatraveler]

Hola!

El siguiente query tarda una eternidad en mostrarme los resultados (26 segundos):

SELECT COUNT(t1.id_usuario)
FROM t1
INNER JOIN t2 ON t2.id=t1.id_usuario
INNER JOIN t3 ON t3.id_usuario=t1.id_usuario
WHERE
(t1.provincia='VALOR CHAR')
AND (t3.id_organizacion='VALOR INT')
AND (t2.bloqueado='F' AND t2.eliminado='F' AND t2.disponible='T')

En t1 hay 37.000 registros.
En t2 hay 32.000 registros.
En t3 hay 130.000 registros.

A ver si alguien me puede hechar una mano para optimizar la consulta, cualquier idea será bienvenida!

Gracias.

[kakoxvid]

Agregaste indices en las tablas?? Y LO OTRO QUE PODRIAS VER ES EL MOTOR QUE ESTAS USANDO INNODB O MYISAM EL MYISAM ES MAS RAPIDO PERO MAS SEGURO EL INNODB

[datatraveler]

Gracias por contestar.

En cada tabla tengo un campo llamado ID (int, autonum, key) y el tipo de motor es MYISAM.

[jurena]

Si el motor es MyISam, deberías indexar los campos que estén relacionados con esos id auto_increment, es decir, los foreign key. Prueba a cambiar también el orden de los tres parámetros del where, a ver si observas diferencias.
Yo, tras indexar el campo provincia, probaría este orden:
... WHERE
(t3.id_organizacion='VALOR INT')
AND (t1.provincia='VALOR CHAR')
AND (t2.bloqueado='F' AND t2.eliminado='F' AND t2.disponible='T')
También deberías tener indexados los campos que buscas con el where, al menos provincia, porque los id, si son auto_increment, ya están indexados. Quizás no haga falta indexar bloqueado, indexado y disponible, si no tienen mucha cardinalidad. No sé si algún cambio en el orden bloqueado, eliminado, disponible mejoraría algo. Si el id_organización es numérico, quita las comillas; si no es primary key y no está indexado, indéxalo.


Muéstranos la estructura de las tablas, los campos con sus tipos, tamaños, etc.

[datatraveler]

Gracias jurena.

He cambiado el orden de los parámetros del where, pero no he notado ningun cambio.

La estructura de las tablas es la siguiente:
id: int, 11, auto_increment, key
id_usuario: int, 11
sexo: varchar, 1
domicilio_tipo_calle: varchar, 10
domicilio_direccion: varchar, 150
domicilio_poblacion: varchar, 150
cp: varchar, 10
provincia: varchar, 150
pais_residencia: varchar, 50
tipo_documento: varchar, 50
num_documento: varchar, 20
tel_movil: varchar, 50
tel_fijo: varchar, 50
email: varchar, 150
web: varchar, 150
fecha_nacimiento: date
nacimiento_provincia: varchar, 200
nacimiento_poblacion: varhar, 150
nacimiento_pais: varchar, 50
nacionalidad: varchar, 20
estado_civil: varchar, 30
hijos: varchar, 5
edad_hijo_1: varchar, 5
edad_hijo_2: varchar,5
edad_hijo_3: varchar, 5
vivienda_actual: varchar, 60
vehiculo_coche: varchar, 1
vehiculo_moto: varchar,1
vehiculo_ciclomotor: varchar, 1
fecha_actualizacion: datetime

t2:
id: int, 11, auto_increment, key
nombre: varchar, 200
apellido1: varchar, 200
apellido2: varchar, 200
usuario: varchar, 100
contrasenya: varchar, 100
bloqueado: varchar, 1
disponible: varchar, 1
eliminado: varchar, 1
visitante: varchar, 1
cliente: varchar, 1
administrador: varchar, 1
volcado: varchar, 1
migrado: varchar, 1
fecha_alta: datetime
email_registro: varchar, 1
responsable_activacion: varchar, 1
codigo: int, 7
codigo2: bigint, 20

t3:
id: int, 11, auto_increment, key
id_usuario: int, 11
nombre_empresa: varchar, 250
nombre_fiscal: varchar, 250
id_organizacion: int, 11
direccion_tipo_calle: int, 11
direccion: varchar, 250
provincia: varchar, 100
población: varchar, 200
id_sitio: int, 11
id_sub_sitio: int, 11
fecha_entrada: date
fecha_salida: date
periodo_total: int, 11
id_anterior: int, 11
coste: varchar, 100
persona_contacto: varchar, 100
persona_contacto_telefono: varchar, 50
persona_contacto_email: varchar, 180
cargo_persona_contacto: varchar, 50
motivos: varchar, 50
personas: varchar, 20
descripción: text
observaciones: text
posible_ampliacion: varchar, 1
interesa_otros: varchar, 1
cp: varchar, 5
direccion_num: varchar, 6
id_pais: int, 11
ciudad: varchar, 250
otros: text


Ya me dirás si necesitas algo más.

[jurena]

indexa id_usuario de t1.
indexa provincia de t1, pero sólo los 6 primeros caracteres.
indexa id_usuario de t3.
indexa id_organizacion de t3.

luego haces el repair table a cada tabla para que haga los índices y los ponga en uso.

Luego haz una prueba, y cambia el orden de provincia y id_organización en la búsqueda.

dinos qué cardinalidad (cuántos valores distintos) tienen bloqueado, disponible y eliminado. Aunque creo, que ahí no será necesario ni útil el índice.

Nada te digo sobre la estructura, porque se ve que ya está cerrada e imagino que no es el momento de repensarla.

[datatraveler]

jurena, de nuevo gracias!

La cardinalidad de bloqueado, disponible y eliminado son dos; T o F.

Mañana creo los índices y hago las pruebas que me sugieres, y te comento que tal han ido.

En cuanto a la estructura...... en principio, si, esta cerrada, pero no descarto hacer cambios si son absolutamente necesarios.... igualmente agradezco cualquier sugerencia que me puedas hacer, sino para éste caso, para no pecar de lo mismo en próximas ocasiones.

Te sigo contando.

Saludos.

[datatraveler]

Ya indexe los campos que me decías y he hecho las pruebas... ahora tarda menos de 1 segundo!!

Una pregunta, si quiero hacer consultas que incluyan más tablas, es recomendable que también indexe los campos que aparecen en las cláusulas y en las uniones, verdad?

Por último, qué le harías a la estructura de las tablas?

Gracias máquina!

[jurena]

datatraveler,
esto eran cosas fáciles.

Iniciado por datatraveler

Una pregunta, si quiero hacer consultas que incluyan más tablas, es recomendable que también indexe los campos que aparecen en las cláusulas y en las uniones, verdad?

Sí, pero dependerá de algunos factores. Si son tablas MyIsam tienes que indexar tú los campos que empleas como foreign key (en las tablas InnoDB no es necesario, pues ya lo hace el programa), los que usas en las uniones mediante join. Respecto a los empleados en los where te diré que eso dependerá de la cardinalidad. Si la cardinalidad es muy baja, como en los bloqueado, etc., de tu base, no será necesario ni conveniente hacerlo, pues el índice no será usado y ocupará espacio.
Un par de consejos más
1) haz pruebas cambiando el orden de los datos buscados tras el where para ver cuál es más rápido.
2) usa EXPLAIN antes de la consulta para ver qué nos falta por mejorar. Si analizas ese explain podrás sacar alguna conclusión acerca de cómo mejorar la consulta.

Por último, qué le harías a la estructura de las tablas?

Si saber para qué sirve cada tabla y cuáles son tus objetivos, no puedo ayudarte mucho. Me da la impresión de que estás usando en las tres tablas datos que podrían estar en una, pero tampoco estoy seguro con la información de que dispongo; veo tipos de campo que podrían ser distintos, aunque, como te digo, no puedo aconsejarte sin disponer de mayor información. No sé cuáles son las entidades, sus atributos, etc., cómo has aplicado las reglas de normalización.