Diferencias de rendimiento entre filtrar con joins o con in

Preguntado hace 1 año

JuanP

JuanP

481Distinciones de plata1Distinciones de bronce6
Votos
PositivosNegativosTotal
3 0 3
88 Visualizaciones
Compártelo: Compártelo en twitterCompártelo en Facebook

Buenas, estamos debatiendo en la oficina para tratar de llegar a un acuerdo en la codificación sobre los filtros. Valoramos rendimiento y legibilidad. Primero rendimiento y luego legibilidad. Quería recabar más opiniones. Unos proponen el uso de "in"

select * from a where a.a_1 in (select b_1 from b where b_2 = 3)

Dicen que el rendimiento es parecido y es más fácil de leer.

Los otros que da mejor rendimiento usar joins

select * from a alias_a, b alias_b
where alias_a.a1 = alias_b.b_1
and alias_b.b_2 = 3

¿Qué opinais?

Actualizando datos

2 Respuestas

Hace 1 año

José Doval
Votos
PositivosNegativosTotal
404

En general los SGBD (y en particular Oracle) hacen tantas optimizaciones internas que en la mayoría de los casos las diferencias de rendimiento son mínimas, por lo que si yo tuviese que decidir me decantaría por la opción más fácil de mantener, es decir, la más legible (que en sí es una condición subjetiva al equipo de desarrollo).

Sobre el papel, aunque ciertos factores pueden afectar (tablas muy grandes ralentizan más los JOIN, índices pueden acelerar, etc.), en general es más eficiente un JOIN, ya que en la cláusula WHERE entran en funcionamiento los índices y las cachés del SGBD, cosa que no ocurre con la Subselect, al no haber constantes ni rangos fijos en dicha cláusula (hablo del primer WHERE en el caso de la Subselect).

En resumen, yo me decanto por la legibilidad. Y en mi caso, también creo que la más legible y mantenible es la Subselect, ya que a la hora de hacer pruebas se puede ejecutar la subconsulta independientemente.

Cerrar

Hace 1 año

Ricardo González
Votos
PositivosNegativosTotal
101

Hola Juan,

En Oracle puedes comprobar el coste de ejecución de las sentencias utilizando autotrace:

http://download.oracle.com/docs/cd/B10500_01/server.920/a96533/autotrac.htm

Con esto obtendrás el plan de ejecución en el que se indica el coste de la sentencia detallando el coste de cada join, in, like, subselect, etc... que contenga.

No obstante, yo apostaría sin ejecutar el autotrace, a que el coste de la segunda consulta es bastante inferior, y más aún si se están utilizando indices.

Saludos, Ricardo

Cerrar

Tu respuesta

Confirmación

Cerrar

Si sales ahora, perderás los cambios. ¿Estás seguro de querer salir?

Para participar en Babelias, debes estar convenientemente validado. Si ya eres usuario inicia sesión, si no lo eres, te puedes registrar.

Dar una respuesta

Trata de ser descriptivo, usa al menos 25 caracteres