sql - all - rendimiento: selección de unión única frente a selecciones simples múltiples
union all vs union (8)
¿Qué es mejor en cuanto a rendimiento?
Como se ha dicho antes, no hay una respuesta correcta sin contexto.
La respuesta a esto depende de (desde lo alto de mi cabeza):
- la cantidad de unión
- el tipo de unión
- indexación
- la cantidad de reutilización que podría tener para cualquiera de las piezas separadas que se unirán
- la cantidad de datos a procesar
- la configuración del servidor
- etc.
No intente escribir su propio bucle de unión como un grupo de selecciones. Su servidor de base de datos tiene muchos algoritmos inteligentes para hacer combinaciones. Además, su servidor de base de datos puede usar las estadísticas y el costo de acceso estimado para elegir dinámicamente un algoritmo de combinación.
El algoritmo de unión del servidor de la base de datos es, por lo general, mejor que cualquier cosa que invente. Saben más acerca de la E / S física, el almacenamiento en caché y lo que no.
Esto le permite enfocarse en su dominio problemático.
Si está utilizando SQL Server (no estoy seguro de si está disponible con otros RDBMS), le sugiero que agrupe un plan de ejecución con los resultados de la consulta. Esto le dará la capacidad de ver exactamente cómo se están ejecutando sus consultas y qué está causando cuellos de botella.
Hasta que sepa qué está haciendo realmente SQL Server, no aventuraría una adivinanza sobre qué consulta es mejor.
Si su base de datos tiene muchos datos ... y hay varias combinaciones, utilice la indexación para un mejor rendimiento.
Si hay uniones externas izquierda / derecha en este caso, entonces use selecciones múltiples.
Todo depende de su tamaño db, su consulta, los índices (que incluyen claves primarias y extranjeras también) ... No se puede llegar a la conclusión con sí / no en su pregunta.
Solo hay una forma de saber: medir el tiempo.
En general, creo que una sola combinación permite que la base de datos haga muchas optimizaciones, ya que puede ver todas las tablas que necesita para escanear, la sobrecarga se reduce y puede generar el conjunto de resultados localmente.
Recientemente, tuve alrededor de 100 select-statements que cambié a JOIN en mi código. Con algunos índices, pude pasar de 1 minuto de funcionamiento a aproximadamente 0,6 segundos.
Todo depende de cómo la base de datos optimizará las uniones y el uso de índices.
Tuve una consulta lenta y compleja con muchas combinaciones. Luego lo subdividí en 2 o 3 querys menos complejas. La ganancia de rendimiento fue asombrosa.
Pero al final, "depende", tienes que saber dónde está el cuello de botella.
Una cosa a considerar además de lo que se ha dicho, es que los seleccionados devolverán más datos a través de la red de lo que las uniones probablemente lo harán. Si la conexión de red ya es un cuello de botella, esto podría empeorar las cosas, especialmente si esto se hace con frecuencia. Dicho eso, su mejor apuesta en cualquier situación de rendimiento es probar, probar y probar.
Una unión única generalmente superará múltiples selecciones simples. Sin embargo, hay demasiados casos diferentes que se ajustan a su pregunta. No es sabio agruparlos bajo una sola regla simple.
Más importante aún, una sola unión generalmente será más fácil de entender y de revisar para el siguiente programador, siempre que usted y el siguiente programador "hablen el mismo idioma" cuando usa SQL. Estoy hablando del lenguaje de conjuntos de tuplas.
E igualmente importante es que el diseño físico de la base de datos y el diseño de consultas deben centrarse primero en las preguntas que darán como resultado una mejora de diez por una velocidad, no en una aceleración del 10% de velocidad. Si estuvieras haciendo miles de selecciones simples frente a una sola, podrías obtener una ventaja de diez por uno. Si está haciendo tres o cuatro selecciones simples, no verá una gran mejora en un sentido u otro.