query lenta solo cuando uso OR

[Patriarka]

Hola gente,
tengpo una query que relaciona 2 tablas con 3 y 5 millones de registros cada una,
el problema es que cuando agrego un OR tarda años en ejecutarse:
el filtro con el problema:

AND (
COLUMNA1 = '9999999999' OR COLUMNA2 = '9999999999' OR COLUMNA3 = '9999999999'
);

en caso que solo filtre por una columna cualquiera de las mencionadas la query se ejecuta al instante:


AND COLUMNA1 = '9999999999';

NOTA: las columnas COLUMNA1 , COLUMNA2 y COLUMNA3 son indices en una tabla


qué podria estar pasando? sospecho que el OR esta el problema de la lentitud pero no puedo comprobarlo, alguna ayuda?

[quimfv]

Si claro el problema estará ahi, es mas con lo que nos dices no hay la mas minima duda, pero sin ver el resto de la query ni saber que es lo que se pretende con ella es dificil de dar una ayuda.

Recuerda que SQL es declarativo, luego hay que saber que es lo que se esta declarando para optimizarlo.

[Patriarka]

hola amigo, la query esta explicada pero bueno seria algo asi:

Código MySQL:

SELECT distinct a.idregistro
 from TABLAB b inner join TABLAA a on a.CAMPOFK = b.CAMPOFK
FROM (
a.CAMPOFK = '9999999999' OR a.CAMPOFK2 = '9999999999' OR a.CAMPOFK2 = '9999999999'
);
 

tablaB tiene 4millones de registros y tablaA tiene 2 millones.
campofk,campofk2 y campofk3 son foreinkey

[gnzsoloyo]

hola amigo, la query esta explicada pero bueno seria algo asi:

Bueno, como hemos dicho otras veces, los "algo así", no sirven para ver los problemas reales. La inmensa mayoría de las veces al simplificar están omitiendo información crucial.
Siempre es conveniente postear la query exactamente como está ecrita en la realidad. Trabajar en base a "parecidos" raramente permite diagnosticos adecuados.
Ahora bien, si me atengo a tu ejemplo, veo este segmento:

Código MySQL:

a.CAMPOFK2 = '9999999999' OR a.CAMPOFK2 = '9999999999'
 

Donde estás comaprando dos veces contra el mismo campo, con el mismo valor. O la simulacion es incorrecta, o hay un defecto en esa consulta.

En cualquier caso, sería bueno saber cuál es la cardinalidad que existe en la relación entre TablaB y TablaA, así como también cuál es la selectividad de los campos de FK mencionados (se entiende por tal que mientras menor es la cantidad de veces que A se relaciona con B, el uso del indice tiene mayor impacto).

¿Probaste usar EXPLAIN con esa consulta, para ver qué optimizaciones sugier MySQL?

[Patriarka]

Hola si estas en lo correcto
el filtro es a.CAMPOFK2 = '9999999999' OR a.CAMPOFK3 = '9999999999'

en cuanto al resumen de la query se debe a dectecté que el problema esta en este filtro, si se lo quito la query en una luz , asi hayan millones de registros
ademas para que me ayuden en lo concreto

gracias

[gnzsoloyo]

¿Probaste lo que te dije, de usar EXPLAIN par que MySQL te diga cómo está ejecutándola?
Con la información que devuelve el EXPLAIN, se puede ver por dónde está perdiendo el tiempo.
Por otro lado, ¿Esas dos FK, están realmente indexadas? ¿Son FGK reales de una tabla InnoDB o es una tabla MyISAM?
En el primer caso, tal vez sea buena idea realizar el JOIN contra la tabla relacionada en ambos casos. En el esegundo, sería conveniente indexarlos.
Pero seguimos dando vuelta a un asunto: Sería buena idea que nos mostraras la quer REAL...
AL menos para sacarnos la duda de si no estás omitiendo información relevante, de esa que no estás viendo.

[Patriarka]

no hay nada que ocultar,
las tablas son MYISAM.

los 3 campos son FK, quizas tenga que reindexzarlos pero como lo haria de una manera correcta?
el phpmyadmin explota cada vez que quiero reindexarlos

[gnzsoloyo]

Si las tablas son MyISAM, los campos no son realmente FK. Al menos no son veraderas FK, sino que las administras por programación.
Las tablas MyISAM no poseen restricciones de foreign key, por lo que podría perfectamente haber datos sucios, si se produjo en algún momento un error de procesos (nada raro, por cierto).
La diferencia entre una y otra cosa es notable, porque las InnoDB, al definir una FK crean un índice real sobre ambos campos, y por consecuencia en las consultas ese índice tiene incidencia en la optimización del parser.
En definitiva, el primer problema a resolver es que tienes que indexar esos campos, es decir, debes al menos contruir un índice sobre cada uno de ellos.

el phpmyadmin explota cada vez que quiero reindexarlos

Bueno, phpMyadmin no es MySQL, sino una interfaz programada en PHP, para acceder de modo amigable a MySQL. Puede tener y tiene errores de diseño, aunque no sean errores de programación.
La mejor solución en ese caso es indexarlos por fuera del phpMyadmin, muy probablemente usando la consola propia de MySQL, o bien una herramienta realmente buena, como MySQL Workbench, por ejemplo.

Pero insisto en una cosa: No has probado el EXPLAIN.

¿Entiendes a qué me refiero cuando lo menciono?

[Patriarka]

el EXPLAIN no me da nada raro como para preocuparme.

entonces queres decir que al reindexar tablas MyISAM no asegura la optimizacion como las innoDB?
seria conveniente pasar de un tipo de tabla a otro?

[gnzsoloyo]

el EXPLAIN no me da nada raro como para preocuparme

¿Podrías, por favor, postearnos el resultado del EXPLAIN?

entonces queres decir que al reindexar tablas MyISAM no asegura la optimizacion como las innoDB?

Reindexar tablas MyISAM no tiene NINGUN efecto sobre las InnoDB. Son motores de tablas completamente diferentes.
Y además yo no estoy hablando de reindexar las tablas, sino de crear índices sobre lesas columnas.

seria conveniente pasar de un tipo de tabla a otro?

Eso es una decisión de diseño. Dependera de lo útil que te resulte, pero con la poca información que sobre las tablas nos das... la verdad no tenemos mucho para decirte al respecto.
Lo que si, ten en cuenta que al pasar de un o a otro tipo, y poner verdaderas FK en esas columnas, pueden aparecer todos los errores de datos que existan.. lo que te llevará tiempo depurar.