SQL mejor práctica para tratar con el orden de clasificación predeterminado

Question

Una gran cantidad de código SQL que he leído, parece que el desarrollador supone que el orden de clasificación predeterminado siempre se cumple. Por ejemplo, al crear una lista de selección de HTML, solo SELECT id, name FROM table sin emitir una cláusula ORDER BY.

Según mi propia experiencia, parece que dbms siempre pide datos usando FIFO si no se da ninguna cláusula ORDER BY y no hay índice. Sin embargo, la orden no está garantizada. Pero nunca he visto un dbms reordenando datos si no hay cambio en la tabla.

¿Alguna vez ha experimentado un DBM seleccionando datos en un orden no determinista si no hay cambio en la tabla?

¿Es una buena práctica poner siempre una cláusula ORDER BY?

Answer 1

No hay un orden de clasificación predeterminado. Incluso si la tabla tiene un índice agrupado, no se garantiza que obtenga los resultados en ese orden. Debe usar una cláusula order by si desea un pedido específico.

Answer 2

Si desea que los datos salgan ordenados consistentemente, sí, tiene que usar ORDER BY.

Answer 3

Sí. No hay una "orden predeterminada" sin una ORDEN POR, y no hay garantía de que obtendrá los datos nuevamente en FIFO/LIFO o en cualquier otra orden.

En lo que a los desarrolladores el uso de "SELECT ID, el nombre de la tabla", o bien están inepto o no les importa qué orden nada aparece.

Answer 4

No RDBMS graves garantiza cualquier orden a menos que especifique un ORDER BY explícito.

Todo lo demás es pura suerte o anectodal: si desea realizar el pedido, debe especificar ORDER BY - no hay forma de evitarlo.

Answer 5

Quizás los redactores de las consultas SQL que estás leyendo no se preocupen por el orden de los datos devueltos. La mejor práctica es usarlo donde necesite para asegurar que se devuelva el orden de los resultados.

Answer 6

Si desea los datos ordenados, la única manera de garantizar algo (con todos los sistemas RDBMS importantes que conozco, sin duda Sql Server y Oracle) es incluir una cláusula ORDER BY. FIFO no tiene absolutamente nada que ver con el orden en que se devuelven los datos sin una cláusula ORDER BY, y no existe un concepto de ningún tipo de orden de clasificación DEFAULT. El llamado orden de clasificación DEFAULT es básicamente sin embargo el motor obtiene los datos, que pueden ser literalmente cualquier orden basada en índices, datos almacenados en caché, consultas de ejecución simultáneas, carga en el servidor, etc., etc.

This other stackoverflow thread es básicamente cubriendo el mismo concepto en relación con Sql Server, AlexK blogged a repo para demostrar el comportamiento.

Answer 7

Incluso una consulta simple como SELECT ... FROM table puede devolver datos en varios orden. Sé que esto es cierto en teoría, sé que esto es cierto en la práctica, y he visto muchos casos cuando el orden cambia entre ejecuciones posteriores, incluso cuando no se producen cambios de datos en la tabla.

Un ejemplo típico de cambios de orden entre ejecuciones es cuando la consulta se ejecuta utilizando un plan paralelo. Dado que los operadores paralelos devuelven datos a medida que los hilos subyacentes lo producen, el orden de las filas en el resultado varía entre cada ejecución. Esta situación hace que incluso el simple SELECT en su ejemplo devuelva resultados completamente diferentes cada vez que se ejecuta.

Answer 8

Como los otros carteles mencionan, si no especifica un orden de clasificación, el estándar SQL dice que los resultados pueden ser en cualquier orden que el procesador de consultas considere más conveniente y eficiente.

Digamos que hace un simple SELECT desordenado para todas las filas de una tabla CUSTOMER, que no tiene índices ni clave principal. Es bastante posible, e incluso probable, que el procesador de consultas realice un escaneo de tabla directo y produzca las filas en el orden en que se insertaron originalmente (lo que le da el comportamiento FIFO que vio).

Si agrega un índice en los campos ESTADO y CIUDAD (en ese orden), y luego consulta WHERE STATE = 'NY', el procesador de consultas puede decidir que es más eficiente escanear las entradas de índice para ESTADO = 'NY' en lugar de una exploración de tabla completa. En este caso, probablemente materialice las filas en orden ESTADO, CIUDAD.

Incluso esto no es seguro. Por ejemplo, si el procesador de consultas ha reunido estadísticas que muestran que casi todos los valores STATE en su tabla son 'NY' (tal vez porque la base de datos es para un negocio de alquiler de equipos basado en Albany), puede decidir que el escaneo de tabla sea más barato que el escaneo de índice, y verá FIFO nuevamente.

Es una buena idea aprender algunos conceptos básicos sobre cómo su base de datos planifica sus consultas. Puede usar la declaración EXPLAIN para ver cómo su DBMS ejecutaría cualquier consulta dada, y luego usar esto para optimizar su consulta, en algunos casos por órdenes de magnitud. Esta es un área fascinante y útil para aprender.

Answer 9

En mi experiencia con SQL, la mayoría de las veces no se especifica una ORDEN DE en SQL, ya que los conjuntos de registros se muestran en una "del lado del cliente" control de tipo rejilla, etc., donde dinámico la ordenación es compatible; en este caso, el ordenamiento por SQL es innecesario, ya que se revisará en el lado del cliente de todos modos.

Esto también se hace en el lado del cliente porque la misma consulta se puede usar para mostrar los datos en diferentes lugares en diferentes órdenes.

Por lo tanto, no es más que la mejor práctica para poner en un ORDER BY, cuando

• El orden de los datos ES importante; y
• La clasificación es más eficiente en el nivel de base de datos.

es decir, si el desarrollador frontal va a "reordenarlo" de todos modos, no tiene sentido, ya que es poco probable que ahorre tiempo de procesamiento general.

Answer 10

Estoy escribiendo esto en caso de que alguien quisiera utilizar esto como lo hice yo.

Bueno, estoy obteniendo un orden de clasificación por defecto satisfactorio, digamos para tablas de registro, con ordenación en Índice. Por ejemplo, normalmente me interesan las últimas filas de la tabla de registro (LIFO), por lo que configuro DateTime DESC como pedido. También probé por diversión agregar Index en el otro campo (entero) al lado de la clave principal y funcionó.

CREATE TABLE [dbo].[tableA]([DateTime] [datetime] NOT NULL, 
CONSTRAINT [PK_tableA] 
PRIMARY KEY CLUSTERED ([DateTime] DESC) 
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]) ON [PRIMARY] 

O en SSMS ...