Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

195
Views
¿Es posible optimizar aún más esta consulta MySQL?

Estaba ejecutando una consulta de este tipo de consulta:

 SELECT -- fields FROM table1 JOIN table2 ON (table1.c1 = table.c1 OR table1.c2 = table2.c2) WHERE -- conditions

Pero el OR lo hizo muy lento, así que lo dividí en 2 consultas:

 SELECT -- fields FROM table1 JOIN table2 ON table1.c1 = table.c1 WHERE -- conditions UNION SELECT -- fields FROM table1 JOIN table2 ON table1.c2 = table.c2 WHERE -- conditions

Lo cual funciona mucho mejor, pero ahora estoy revisando las tablas dos veces, así que me preguntaba si había más optimizaciones, por ejemplo, obtener un conjunto de entradas que satisfaga la condición (tabla1.c1 = tabla.c1 O tabla1.c2 = tabla2.c2) y luego consultarlo. Eso me llevaría de vuelta a lo primero que estaba haciendo, pero tal vez haya otra solución que no tengo en mente. Entonces, ¿hay algo más que hacer con eso o ya es óptimo?

over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

Dividir la consulta en dos separadas suele ser mejor en MySQL, ya que rara vez utiliza la operación "Índice OR" ( Fusión de índice en la jerga de MySQL).

Hay algunos elementos en los que me concentraría para una mayor optimización, todos relacionados con la indexación:

1. Filtra las filas más rápido

El predicado en la cláusula WHERE debe optimizarse para recuperar la menor cantidad de filas. Y deben analizarse en términos de selectividad para crear índices que puedan producir los datos con el menor filtrado posible (menos lecturas).

2. Acceso para unirse

La recuperación de filas relacionadas también debe optimizarse. De acuerdo con la selectividad, debe decidir qué tabla es más selectiva y usarla como tabla de control, y considerar la otra como tabla de bucle anidado. Ahora, para este último, debe crear un índice que recupere las filas de manera óptima.

3. Índices de cobertura

Por último, pero no menos importante, si su consulta aún es lenta, hay una cosa más que puede hacer: usar índices de cobertura. Es decir, expanda sus índices para incluir todas las filas de las tablas de control y/o secundarias en ellos. De esta forma el motor InnoDB no necesitará leer dos índices por tabla, sino uno solo.

over 4 years ago · Santiago Trujillo Report

0

Prueba

 SELECT -- fields FROM table1 JOIN table2 ON table1.c1 = table2.c1 WHERE -- conditions UNION ALL SELECT -- fields FROM table1 JOIN table2 ON table1.c2 = table2.c2 WHERE -- conditions /* add one more condition which eliminates the rows selected by 1st subquery */ AND table1.c1 != table2.c1

Copiado de los comentarios:

Nico Haase > ¿Qué quieres decir con "prueba"?

OP muestra solo patrones de consulta. Por lo tanto, no puedo predecir si la técnica es efectiva o no, y sugiero que OP pruebe mi variante en su estructura y matriz de datos.

Nico Haase > lo que has cambiado

He agregado una condición más a la segunda subconsulta: vea el comentario agregado en el código.

Nico Haase > ¿y por qué?

Esto reemplaza UNION DISTINCT con UNION ALL y elimina la ordenación combinada de conjuntos de filas para la eliminación de duplicados.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!