Pregunta Evitar consultas anidadas


Cuán importante es evitar las consultas anidadas.

Siempre aprendí a evitarlos como una plaga. Pero son lo más natural para mí. Cuando estoy diseñando una consulta, lo primero que escribo es una consulta anidada. Luego lo convierto en combinaciones, lo que a veces toma mucho tiempo para hacerlo bien. Y rara vez da una gran mejora en el rendimiento (a veces lo hace)

Entonces realmente son tan malos. ¿Hay alguna forma de utilizar consultas anidadas sin tablas temporales ni archivos?


14
2018-05-06 06:02


origen


Respuestas:


Realmente depende, tuve situaciones en las que mejoré algunas consultas mediante el uso de subconsultas.

Los factores de los que soy consciente son:

  • si la subconsulta usa campos de consulta externa para comparación o no (correlacionado o no)
  • si la relación entre la consulta externa y la sub consulta está cubierta por índices
  • si no hay índices utilizables en las uniones y la subconsulta no está correlacionada y devuelve un resultado pequeño, podría ser más rápido usarla
  • También me he encontrado con situaciones en las que se transforma una consulta que utiliza el orden en una consulta que no lo utiliza y luego se convierte en una subconsulta simple y ordenada que mejora el rendimiento en mysql.

De todos modos, siempre es bueno probar diferentes variantes (con SQL_NO_CACHE, por favor), y convertir las consultas correlacionadas en uniones es una buena práctica.

Incluso llegaría tan lejos como para llamarlo una práctica muy útil.

Es posible que si las consultas correlacionadas son las primeras que te vienen a la mente que no estás pensando principalmente en términos de operaciones de conjunto, sino principalmente en términos de operaciones de procedimiento y cuando se trata de bases de datos relacionales, es muy útil adoptar completamente el conjunto perspectiva sobre el modelo de datos y las transformaciones en él.

EDITAR: Procesal vs Relacional
Pensar en términos de operaciones de conjunto versus procedimientos se reduce a la equivalencia en algunas expresiones de álgebra, por ejemplo, la selección en una unión es equivalente a la unión de selecciones. No hay diferencia entre los dos.
Pero cuando compara los dos procedimientos, como aplicar los criterios de selección a cada elemento de una unión con hacer una unión y luego aplicar la selección, los dos son procedimientos claramente diferentes, que pueden tener propiedades muy diferentes (por ejemplo, utilización de CPU, I / O, memoria).

La idea detrás de las bases de datos relacionales es que no intente describir cómo obtener el resultado (procedimiento), sino solo lo que desea, y que el sistema de administración de la base de datos decidirá la mejor ruta (procedimiento) para cumplir con su solicitud. Es por eso que se llama SQL Lenguaje de cuarta generación (4GL).

Uno de los trucos que te ayudan a hacer eso es recordarte a ti mismo que las tuplas no tienen un orden inherente (los elementos del conjunto no están ordenados). Otro es darse cuenta de que el álgebra relacional es bastante completo y permite la traducción de solicitudes (requisitos) directamente a SQL (si la semántica de su modelo representa bien el espacio problemático o, en otras palabras, si el significado adjunto al nombre de sus tablas y relaciones se realiza correctamente , o en otras palabras, si su base de datos está bien diseñada).

Por lo tanto, no tienes que pensar cómo, solo qué.

En su caso, era solo preferencia sobre las consultas correlacionadas, por lo que podría ser que no le dijera nada nuevo, pero usted enfatizó ese punto, de ahí el comentario.

Creo que si estuvieras completamente cómodo con todas las reglas que transforman las consultas de una forma en otra (reglas como distributiveness) que no preferiría subconsultas correlacionadas (que vería todas las formas como iguales).

(Nota: anteriormente se analizan los antecedentes teóricos, importantes para el diseño de bases de datos; prácticamente los conceptos anteriores se desvían; no todas las reescrituras equivalentes de una consulta se ejecutan necesariamente tan rápido, las claves primarias clúster hacen que las tablas hereden el orden en el disco, etc. las desviaciones son solo desviaciones, el hecho de que no todas las consultas equivalentes se ejecuten tan rápido es una imperfección del DBMS real y no de los conceptos subyacentes)


6
2018-05-06 07:43



No estoy seguro de cómo se ve en MySQL 5.1 o 5.5, pero en 5.0.x las consultas anidadas generalmente tienen un rendimiento horrible, porque MySQL realiza una subconsulta para cada fila obtenida de la consulta principal. Probablemente este no sea el caso para bases de datos más maduras como MsSQL, que internamente puede reescribir consultas anidadas en combinaciones, pero nunca he usado MsSQL, así que no estoy seguro.

http://dev.mysql.com/doc/refman/5.0/en/rewriting-subqueries.html

También es cierto que, en algunas ocasiones, no solo es posible reescribir una consulta sin una subconsulta, sino que puede ser más eficiente utilizar algunas de estas técnicas en lugar de utilizar subconsultas. - que es una declaración bastante divertida, teniendo en cuenta que para mí hasta ahora todas las subconsultas hacen el rastreo de la base de datos.

Subconsultas vs uniones


1
2018-05-06 06:31