asc - La mejor práctica de SQL para manejar el orden de clasificación predeterminado

order by sql server ejemplos

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, simplemente SELECT id, name FROM table nombrarían la SELECT id, name FROM table sin emitir una cláusula ORDER BY .

Desde mi propia experiencia, parece que dbms siempre ordena 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

Como mencionan los otros carteles, 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.

Supongamos que hace un simple SELECT desordenado para todas las filas de una tabla CUSTOMER, que no tiene índices ni claves principales. 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 luego 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 STATE = ''NY'' en lugar de hacer un escaneo de tabla completo. 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 instrucció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 2

En mi experiencia con SQL, la mayoría de las veces no especifico un ORDER BY en SQL, porque los conjuntos de registros se muestran en un control de tipo de cuadrícula "del lado del cliente ", etc. donde se admite la ordenación dinámica, en este caso ordenando por SQL es innecesario ya que se revisará 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, es solo una mejor práctica poner un ORDER BY, cuando

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

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

Answer 3

Estoy escribiendo esto en caso de que alguien quiera usar esto como yo lo hice.

Bueno, obtengo un orden de clasificación predeterminado satisfactorio, digamos para las tablas de registro, con una 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 ...

Answer 4

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 5

Ningún RDBMS serio garantiza ningún pedido a menos que especifique un ORDER BY explícito.

Cualquier otra cosa es pura suerte o anectodal: si quieres un pedido, debes especificar ORDER BY, no hay forma de evitarlo.

Answer 6

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 7

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 cuanto a los desarrolladores que usan "SELECT ID, name FROM table", o son ineptos o no les importa en qué orden aparece algo.

Answer 8

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

Answer 9

Si quiere los datos ordenados, la única manera de garantizar cualquier cosa (con cada sistema RDBMS importante que conozco, definitivamente 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 podrían ser literalmente cualquier orden basada en índices, datos almacenados en caché, consultas de ejecución simultáneas, carga en el servidor, etc., etc.

Este otro subproceso de básicamente cubre el mismo concepto en relación con Sql Server, AlexK escribió un repositorio en el blog para demostrar el comportamiento.

Answer 10

Tal vez los escritores de esas 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.