¿Por qué el costo de SQL explota con el simple "o"?

Question

que tienen la siguiente declaración para encontrar nombres inequívocos en mis datos (~ 1 millón de entradas):

select Prename, Surname from person p1 
where Prename is not null and Surname is not null 
and not exists (
    select * from person p2 where (p1.Surname = p2.Surname OR p1.Surname = p2.Altname) 
    and p2.Prename LIKE CONCAT(CONCAT('%', p1.Prename), '%') and p2.id <> p1.id 
) and inv_date IS NULL 

Oracle muestra un enorme costo de 1477315000 y ejecución no termina después de 5 minutos. Basta con dividir el quirófano en una propia existe el rendimiento aumenta subcláusula a 0,5 s y costos a 45000:

select Prename, Surname from person p1 
where Prename is not null and Surname is not null 
and not exists (
    select * from person p2 where p1.Surname = p2.Surname and 
    p2.Prename LIKE CONCAT(CONCAT('%', p1.Prename), '%') and p2.id <> p1.id 
) and not exists (
    select * from person p2 where p1.Surname = p2.Altname and 
    p2.Prename LIKE CONCAT(CONCAT('%', p1.Prename), '%') and p2.id <> p1.id 
) and inv_date IS NULL 

No es mi pregunta para ajustar esto a lo mejor, ya que es sólo una consulta rara vez ejecutado, y yo sé que CONTACT está superando cualquier índice, pero me pregunto de dónde viene este alto costo. Ambas consultas parecen ser semánticamente equivalentes a mí.

Answer 1

La respuesta está en el PLAN DE EXPLICACIÓN para sus consultas. Pueden ser semánticamente equivalentes, pero el plan de ejecución entre bastidores para sus consultas es muy diferente.

EXISTS funciona de forma diferente a un JOIN y, esencialmente, su declaración de filtro OR es lo que une a las tablas.

No se produce JOIN en la segunda consulta, ya que solo está recuperando registros de una tabla.

Answer 2

Los resultados de sus dos consultas pueden ser semánticamente equivalentes, pero la ejecución no es operativamente equivalente. Su segundo ejemplo nunca utiliza un operador OR para combinar predicados. Todos sus predicados en el segundo ejemplo se combinan usando un AND.

El rendimiento es mejor porque, si el primer predicado que se combina con un AND no se evalúa como verdadero, el segundo (o cualquier otro predicado) se omite, (no se evalúa). Si utilizó un OR, ambos (o todos) los predicados tendrían que evaluarse con frecuencia, lo que ralentizaría su consulta. (Los predicados ORed se marcan hasta que se evalúa como verdadero.)

Answer 3

Consideraría probar la consulta reescrita como a continuación ... Hacer una unión directa de uno a otro en los criterios que "Califica" lo que se considera una coincidencia. .. a continuación, en la cláusula WHERE, a la basura si no llegar a un partido

select 
     p1.Prename, 
     p1.Surname 
    from 
     person p1 
     join person p2 
      on p1.ID <> p2.ID 
      and ( p1.Surname = p2.Surname 
       or p1.SurName = p2.AltName) 
      and p2.PreName like concat(concat('%', p1.Prename), '%') 
    where 
      p1.PreName is not null 
     and p1.SurName is not null 
     and p1.Inv_date is null 
     and p2.id is null 

por sus comentarios, pero por lo que parece que estás buscando ... no, no hacer una combinación externa izquierda ... Si está buscando nombres que son ALIKE que desea PURGAR (independientemente de cómo lo manejará), solo desea PREQUALIFICAR aquellos registros que TENGAN UN PARTIDO a través de la auto-unión (por lo tanto, unión normal). Si tiene un nombre que NO TIENE un nombre similar, es probable que desee dejarlo en paz ... por lo tanto, se quedará automáticamente FUERA del conjunto de resultados.

Ahora, la cláusula WHERE se activa ... Tienes una persona válida a la izquierda ... que TIENE a una persona a la derecha ... Estos SON los duplicados ... así que tienes la coincidencia, ahora tirando en la lógica "p2.ID IS NULL" crea el mismo resultado que NOT EXIST dando los resultados finales.

Devuelvo mi consulta a una "combinación" normal.