Foro de elhacker.net

Bueno siguiendo mi travesía por los mares de consultas y tierras de Optimizacion en el mundo del SQL

-MySQL Importacion de Archivos tipo CSV (Solucionado) (http://foro.elhacker.net/programacion_general/mysql_importacion_de_archivos_tipo_csv_solucionado-t238492.0.html)

-MySQL, reporte "Registros duplicados" (Solucionado) (http://foro.elhacker.net/programacion_general/mysql_reporte_registros_duplicados_solucionado-t234835.0.html)

He llegado al punto de esperar decenas de minutos para ver que la Tabla esta correcta. sin embargo quisiera optimizarla

En tablas con 2 campos esenciales pero que no estan marcados como primarios es necesario encontrar los faltantes de la Tabla A en la Tabla B

Lo he estado haciendo con la siguiente consulta:

SELECT * FROM tabla_A
WHERE(id, grupo)
NOT IN(
SELECT id, grupo FROM tabla_B
GROUP BY id, grupo
HAVING COUNT(*)>1);

El resultado es correcto sin embargo quisiera poder llegar a optimizarla para que no dure tanto, en el segundo link arriba mencionado encontré la optimizacion para una consulta similar (Encontrar duplicados), sin embargo eso era en la misma tabla, en esta ocasión es con una tabla distinta por ello se me complica la optimizacion, he probado con LEFT JOIN sin embargo internamente el proceso es muy similar a la consulta antes mencionada, quisiera saber si conocen una forma de optimizarlo se los agradecería.

Saludos

Te dare una pista que utilizo bastante... y que muchos DBA suelen utilizar ya que es un requisito indispensable para optimizacion de consultas y procedimientos almacenados.

TUNNING....

indaga y conoce la funcion EXPLAIN dentro del motor MySQL  ;)  esta te ayudara mas de lo que te imaginas y tus consultas quedaran bastantes optimizadas.

sin duda ^TiFa^ a de estar en lo correcto , yo no conozco EXPLAIN :/ tendre que leer.

yo tengo una pregunta, ID = identificador de grupo?

digamos, TABLA A

id | grupo |
-------------
1 | grupo A|
2 | grupo B|
3 | grupo C|
4 | grupo D|
5 | grupo E|

Encontrar los grupos que no esten el tabla B
seria algo asi como buscar su identificador nada mas, ya que al tener el identificador tienes el nombre del grupo tambien

SELECT * FROM tabla_A 
WHERE id  NOT IN( SELECT id DISTINCT FROM tabla_B );

por lo menos yo asi lo haria :P, nose si estare en lo correcto


salu2

ID es precisamente eso el indice o la llave primaria de la tabla.... el campo identificador como llave primaria de la tabla, puede llamarse ID, codigo, nombres, como gustes...  :P

Sobre tu pregunta Sempus si es valido, podrias obtener todos los registros de la tabla A donde sus id no sean iguales a los de la tabla B con esa subconsulta, aunque aun desconozco porque utilizas la clausula DISTINC en la consulta al id de la tabla B, si id es una llave primaria o unica de la tabla B no deberia acceptar duplicados, por lo tanto DISTINC no ejerceria ninguna funcion aca, a no ser que como te explico id de la tabla B no sea ningun indice primario y tenga campos repetidos o sea un indice primario secundario.

La consulta es valida para obtener lo que se busca si son datos chiquitos, pero para optimizacion necesitan verificar todo con EXPLAIN

http://dev.mysql.com/doc/refman/5.0/es/query-speed.html

en esta consulta :

SELECT * FROM tabla_A
WHERE id  NOT IN( SELECT id DISTINCT FROM tabla_B );

la tabla B es una subconsulta de la A, y si id es un indice en la tabla B vamos bien en esa parte de optimizacion pero.. la tabla A le estamos haciendo un Select Todo donde su id no este dentro de lo que la subconsulta genera... por lo tanto para que el id de la tabla A obtenga una respuesta para comparar o saber que datos debe devolver, primero tiene que recorrer todos los indices y data de sus archivos devueltos por la tabla B.... y ahi entra el dilema, se puede semi optimizar la tabla A si por ejemplo el campo id no accepta valores Nulos por defecto podrias hacer :

SELECT * FROM tabla_A
WHERE id  NOT IN( SELECT id DISTINCT FROM tabla_B ) and A.id is not null;

Saludos :)

Y de preferencia la consulta hazla directamente al campo que necesitas eliminando  *

SELECT campo FROM tabla_A
consumes menos recursos