problema de consulta

[neneriostb]

hola pues mi problema es q tengo una base de datos de 25000 registro y a la hora de hacer una consulta me bloquea la maquina y sale mensaje de error de falta de memoria ,

y la consulta es :

sELECT * FROM demandantes d inner join infogeneral i where d.ano_radicado=i.ano_radicado and d.cod_radicado=i.cod_radicado and d.cod_juzgado=i.cod_juzgado

por favor necesito una ayuda para optimizar la consulta .

[jurena]

sELECT * FROM demandantes d INNER JOIN infogeneral i ON (d.ano_radicado=i.ano_radicado and d.cod_radicado=i.cod_radicado and d.cod_juzgado=i.cod_juzgado)

imagino que tendrás indexados esos campos por los que realizas el cruce, ano_radicado en, cod_radicado y cod_juzgado en ambas tablas, aunque si alguno es clave primaria ya lo tendrías indexado.

[jurena]

nenerios,
muéstranos la sintaxis de creación de las tablas, para que veamos cuáles son sus campos y relaciones, e índices. También nos vendrían bien algunos datos, para ver cómo los has incluido.

[gnzsoloyo]

La consulta propuesta es ineficiene. La igualación de campos de un JOIN no debe hacerse en el WHERE sino en el JOIN:

Código MySQL:

SELECT * 
FROM demandantes d INNER JOIN infogeneral i 
    ON d.ano_radicado=i.ano_radicado 
    AND d.cod_radicado=i.cod_radicado 
    AND d.cod_juzgado=i.cod_juzgado;
 

Eso puede estar causando problemas.
AL margen de esto, esta vinculación podría ser mucho mejor si estuviese definida por PK y FK, pero no es lo que parece.

Apoyo la idea de Jurena: ¿Cómo son las estructuras de las tablas?

[neneriostb]

hola amigos miren esta consulta

SELECT d.identificacion,d.pnombre,cd.concepto, cd.actos,cd.fecha_causacion , cd.valor , i.demandado,ad.pnombre as apoderado, concat(i.ano_radicado," - ",i.cod_radicado) as radicado,j.nombre as juzgado, i.estado_proceso,ec.njudicial ,ec.valorjudicial,ec.fechapago ,i.observacion FROM demandantes d,concepto_demandantes cd,infogeneral i ,juzgado j, apoderado_demandante ad ,embargo_cuentas ec where (i.cod_juzgado=j.codigo and i.ano_radicado=ad.ano_radicado and i.cod_radicado=ad.cod_radicado and i.cod_juzgado=ad.cod_juzgado and i.ano_radicado=ec.ano_radicado and i.cod_radicado=ec.cod_radicado and i.cod_juzgado=ec.cod_juzgado and d.identificacion=cd.identificacion and d.cod_juzgado=cd.cod_juzgado and d.ano_radicado=cd.ano_radicado and d.cod_radicado=cd.cod_radicado )

se me desmora mucho por responder a esa consulta , cuando la hago con limites de 10000 pero cuando la dejo sin limites se desmora mucho y se cuelga .

esa consulta la estoy haciendo directa y ya tengo los campos indexadas : cod_radicado,ano_radicado,cod_juzgado ,identificaion


y cada tabla q tengo hay tiene 23000 registros

por favor es de gran ayuda me urge

[jurena]

nenerios,
como te dice gnzsoloyo, primero haz las uniones entre tablas con INNER JOIN... ON y los campos de las tablas; luego otro INNER JOIN con otra tabla y el ON..., etc. No uses para eso los WHERE, como estás haciendo.
Revisa que todos los campos que unes en el ON sean clave primaria (ya está indexada de por sí) o si no lo son indéxalos tú.
Y, finalmente, pagina la consulta para mostrar menos datos, y no todos de un golpe.

[neneriostb]

mmmm caa inner join va con una tabla y su union , voy hacerlo no habia entendido ,

y pues asi es las q estan dentro del on estan indexadas

es q para paginarlas me tocaria hacer varias consultas osea 1 que vaya de 0, 1000 luego otra consulta q vaya de 1000 a 2000 cierto ? asi si q es gayudo

[jurena]

nenerios, en realidad tú no muestras 1000 referencias, o si lo haces, el cliente que bajar mediante el scroll poco a poco para poder todas las referencias. Las normas en una página web, una de ellas (y seguro que hay opiniones) recomienda que como mucho la página ocupe página y media. Tú lo que haces es paginar resultados; para lo cual te ayudarán en los foros de programación. En MySqL usas Limit y offset, y con unas variables cada vez que avanzas la página, vuelve a lanzar la consulta para traerse, por ej., los 30 siguientes. Si haces un limit 30 podrás comprobar cómo la consulta es mucho más rápida.