desc - SQL Server UNION: cuál es el comportamiento ORDER BY predeterminado

sql order by date

Question

Si tengo unas pocas declaraciones UNION como un ejemplo artificial:

SELECT * FROM xxx WHERE z = 1
UNION
SELECT * FROM xxx WHERE z = 2
UNION
SELECT * FROM xxx WHERE z = 3

¿Cuál es el order by predeterminado order by comportamiento?

Los datos de prueba que estoy viendo esencialmente no devuelven los datos en el orden que se especifica arriba. Es decir, los datos están ordenados, pero quería saber cuáles son las reglas de precedencia sobre esto.

Otra cosa es que en este caso xxx es una Vista. La vista une 3 tablas diferentes para devolver los resultados que quiero.

Answer 1

Acabo de encontrar la respuesta real.

Como UNION elimina duplicados, realiza una CLASIFICACIÓN DISTINTA. Esto se hace antes de que todas las declaraciones de la UNIÓN se concatenen (consulte el plan de ejecución).

Para detener una clasificación, realice UNION ALL y esto tampoco eliminará los duplicados.

Answer 2

Desde mi experiencia práctica, puedes cambiar el orden usando "UNION" contra "UNION ALL" ... es decir, si tu consulta es como

Select Count(*) from Table A
UNION
Select Count(*) from Table B
result is
10
26

puede cambiar el orden reemplazando "UNION" con "UNION TODO" ... luego el resultado será

26
10

Answer 3

En lo que respecta a agregar una cláusula ORDER BY:

Esto es probablemente elemental para la mayoría aquí, pero pensé que agrego esto. A veces no quiere que los resultados se mezclen, por lo que desea los resultados de la primera consulta y luego el segundo, y así sucesivamente. Para hacer eso, simplemente agrego una primera columna ficticia y ordeno por eso. Debido a posibles problemas con el olvido de alias de una columna en uniones, suelo usar ordinales en la cláusula order by, no en los de columna.

Por ejemplo:

SELECT 1, * FROM xxx WHERE z = ''abc''
UNION ALL
SELECT 2, * FROM xxx WHERE z = ''def''
UNION ALL
SELECT 3, * FROM xxx WHERE z = ''ghi''
ORDER BY 1

La columna ordinal ficticia también es útil para los momentos en los que voy a ejecutar dos consultas y sé que solo uno devolverá los resultados. Entonces puedo verificar el ordinal de los resultados devueltos. Esto me ahorra tener que hacer múltiples llamadas a la base de datos y la mayoría de las comprobaciones de conjuntos de resultados vacíos.

Answer 4

Es muy común encontrar un código mal escrito que asume que los datos de la tabla se devuelven en orden de inserción, y el 95% de las veces el programador se sale con la suya y nunca es consciente de que esto es un problema como en muchas bases de datos comunes (MSSQL, Oracle, MySQL). Por supuesto, es una falacia completa y siempre debe corregirse cuando aparece, y siempre, sin excepción, usa una cláusula Order By usted mismo.

Answer 5

No hay un orden por defecto

Sin una cláusula Order By, el pedido devuelto no está definido. Eso significa que SQL Server puede devolverlos en el orden que quiera.

EDITAR: en función de lo que he visto, sin una orden por, el orden en que vuelvan los resultados depende del plan de consulta. Entonces, si hay un índice que está usando, el resultado puede regresar en ese orden pero nuevamente no hay garantía.

Answer 6

Un UNION puede ser engañoso con respecto al orden de los conjuntos de resultados porque una base de datos a veces usará un método de ordenamiento para proporcionar el DISTINCT que está implícito en UNION, lo que hace que parezca que las filas se ordenan deliberadamente; esto no se aplica a UNION ALL para lo cual no hay una diferencia implícita, por supuesto.

Sin embargo, existen algoritmos para las diferencias implícitas, como el método hash de Oracle en 10g +, para el cual no se aplicará ningún orden.

Como dice DJ, siempre use una ORDEN DE

Answer 7

Si le importa qué orden se devuelven los registros, DEBE usar un pedido de.

Si lo deja de lado, puede parecer organizado (según los índices elegidos por el plan de consulta), pero los resultados que ve hoy NO son los que espera, e incluso podría cambiar cuando se ejecute la misma consulta mañana.

Edición: algunos ejemplos buenos y específicos: (todos los ejemplos son servidores MS SQL)

• El blog de Dave Pinal describe cómo dos consultas muy similares pueden mostrar un orden aparente diferente, porque se usan índices diferentes:

  SELECT ContactID FROM Person.Contact
  SELECT * FROM Person.Contact

• Conor Cunningham muestra cómo el orden aparente puede cambiar cuando la tabla aumenta (si el optimizador de consultas decide usar un plan de ejecución paralelo).

• Hugo Kornelis demuestra que el orden aparente no siempre se basa en la clave primaria. Aquí está su publicación de seguimiento con explicación.