Ya te entendi, aunque dejame decirte que eso que pides por NOrmalizacion, no existe o sea se da el caso que pides y es posible hacerlo en 2 tablas distintas... pero en 1 misma tabla a la vez? O sea esa condicion que pides de verdad no suele darse en una misma tabla... Estoy buscando una via factible.. aunque esto se salga de la Normalizacion puedes probar hacer esto ::


Recuerda que en ambos campos hay distintos numeros de columnas con registros repetidos y por este hecho no pueden caer ambos campos juntos, por ende estoy buscando una forma de no utilizar NULL para rellenar los faltantes..... Pero realmente no es algo comun de ver.

Creo que ahi tienes tu respuesta, si era eso lo que estabas buscando que aun no lo se    tengo una confusion sobre si son todos los registros que se repiten en cada campo o es todos los registros que concuerdan en los 2 campos...

Pero sea cual sea el caso, espero que la respuesta anterior te haya servido
Aunque no veo la necesidad de tantos CONCAT.

 

Si tienes razon no necesitaba tantos concat .
 
Me tomo 5 min. hacerlo no tuve tiempo ( eso tan escurridizo ) de optimizar nada , vi el post dije a ver funcionara asi?? y funciono.

La proxima me tomare una media de 10 min. para hacer una consulta n_n o revisare mi consulta para ver que mejorarle .

Un consejo para Anon , no te compliques con cosas sencillas .

Saludos¡¡

El nino no se complica es normal que pregunte.

Mi caso fue peor que no comprendi en todo el post que era lo que realmente el estaba solicitando .. nisiquiera porque me lo explico con cucharitas 

Yo tenia claro en mi cabeza que el deseaba todos los registros que se repetian en ambos campos sin importar si conjugaban o no en los 2 al mismo tiempo.... y me estaba haciendo un ocho porque una peticion asi es un poco imposible... porque rompe el agrupamiento de los registros al haber mas o menos duplicados en cada campo... 

Pero me alegra sobremanera.. que otro nino haya entendido la peticion en si, y haya podido ayudarte    creo que a partir de ahora estaras mas amistoso con Mysql 

Anon que bueno que continues aprendiendo mas MySQL.

Ahora, obviamente esta consulta :

SELECT * FROM tablaWHERE(id, grupo)IN(SELECT id, grupo FROM tablaGROUP BY id, grupoHAVING COUNT(*)>1);
 

Tarda una vida entera en una tabla con una cantidad de registro enormes... hablamos de millones. Y la respuesta es mas que simple, en la consulta anterior no se esta filtrando por indices en ninguna parte, en el primer caso expuesto por ti, al ser 7000 registros pues la cosa no era complicada y no merecia filtrar la verdad sobretodo con la rapida respuesta de MySQL con las clausulas SELECT en tablas MyIsam.

Pero por experiencia personal, cuando debes hacer una consulta de registros masivos digamos millones de estos.. nosotr@s filtramos por indices. He visto tablas en Oracle donde inclusive el DBA creaba hasta 20 indices, y todo precisamente para que los analistas pudiesemos filtrar efectivamente y optimizar una consulta y no tardar 30 minutos esperando algo que puedo obtener en segundos con indices. Pero subsecuentemente te iras familiarizando mas y mas con cada necesidad de SQL el camino no es corto, pero vale la pena.

Tengo una anecdota muy peculiar, un programador profesional en PHP que conozco que hace gala de su certificaciones en Zend de PHP y de su diplomado universitario, y de que el sigue las reglas estructuradas de programacion y que el y que el... en fin, me intento discutir que era imposible realizar dentro de MySQL una consulta a 50 millones de registros donde esta no tardaze mas de 3 minutos. A lo cual le dije, yo puedo asegurarte dependiendo que consulta estas realizando que no la se, que no hay necesidad de que esto tarde tanto... y el insistia que si que si, que MySQL apestaba con devolver muchos registros, que era lento, etc...

Asi que hice algo similar a ti, pero no con C (El Api C de MySQL por cierto me encanta) cree una sencilla tabla en MySQL con 3 campos, id, nombre, apellido. Donde id era una llave primaria y nombre / apellido indices. Luego cree un Procedimiento Almacenado dentro de mi MySQL con un bucle que me lleno la tabla de registros hasta que alcanzo los 50 millones.... al finalizar.

Asi que procedi a hacer lo mismo que ignorantemente hacia mi amigo PHPlero al consultar 50 millones de registros (Mas para comprobarle a el, que el problema no era MySQL en si, sino el que no sabia generar una consulta SQL satisfactoria):

SELECT * FROM tabla;
 

Eso me tardo obviamente unos 5 o 6 minutos en devolver... mas sin embargo utilize un poco de Tunning para exponer mi segunda consulta.

EXPLAIN SELECT * FROM TABLA WHERE id IS NOT NULL AND nombres IS NOT NULL AND apellidos IS NOT NULL; 
 

Luego de verificar el Tunning con Explain, vi que esa consulta estaba optimizada para el ejemplo que deseaba exponer a mi amigo, asi que la ejecute... y de 5 minutos.. esta bajo a 1 minuto, procedi a ejecutarla la tercera vez y de 1 minuto redujo finalmente a 0.70 segundos (Gracias a la Cache)

EN resumen, mi amigo no estaba utilizando indices, no tenia la Cache de MySQL activada tampoco.. y no utilizaba Tunning para evaluar que consulta SQL era la mas satisfactoria. Claro esto vas conociendolo en el camino repito.

Otra recomendacion que te puedo ofrecer Anon, si vas a guardar datos caracteres menores a 20 caracteres, procura utilizar CHAR en vez de VARCHAR.

CHAR consume muchisimo menos memoria Ram a la hora de lectura de datos en una consulta, y los datos tipo CHAR tienden a no corromperse facilmente cuando hay fallas por alguna razon en las transacciones. VARCHAR es mas vulnerable, y a no ser que sea extremadamente necesario ya sea que vayas a guardar una info un pelin larga yo suelo utilizar mas CHAR, es cierto que CHAR consume mas espacio de disco porque su tamano no es variante sino constante sin importar la cantidad de caracteres que ingreses, pero.. es mas estable a soportar fallas y es mas rapido en devolver a lecturas de consultas. En el caso de VARCHAR su tamano al ser variante pues se tarda unos segundos mas ya que la base de datos sea cual sea no solo aplica para MySQL, tiene que verificar el espacio consumido por un dato en el HD antes de seguir verificando hacia el otro dato y asi sucesivamente...

Despues de todo, me alegra sobremanera que estes animado a seguirle

Buena suerte en tu camino, son pocos los jovenes que dedican su tiempo en aprender cosas productivas como SQL en vez de ponerse a jugar con crack y troyanitos que a la larga no les servira de nada.