Ordenamiento de fila predeterminado para seleccionar consulta en oracle

En Oracle, ¿cuál es el orden predeterminado de las filas para una consulta de selección si no se especifica una cláusula de “orden por”.

Lo es

  1. el orden en que se insertaron las filas
  2. no hay ningún orden predeterminado en absoluto
  3. Ninguna de las anteriores.

Según Tom Kyte: “A menos que y hasta que agreguen” ordenar por “a una consulta, no se puede decir NADA sobre el orden de las filas devueltas. Bueno, salvo” no se puede confiar en el orden de las filas que se devuelven “.

Vea esta pregunta en asktom.com.

En cuanto a ROWNUM, no existe físicamente, por lo que no puede ser “liberado”. ROWNUM se asigna después de recuperar un registro de una tabla, por lo que “WHERE ROWNUM = 5” siempre dejará de seleccionar cualquier registro.

@ammoQ: es posible que desee leer este artículo de AskTom sobre el pedido GROUP BY. En breve:

¿Una cláusula Agrupar por en una garantía de consulta que los datos de salida se ordenarán en las columnas Agrupar por en orden, incluso si no hay cláusula Ordenar por?

y dijimos …

ABSOLUTAMENTE NO,

Nunca lo hizo, nunca lo hizo, nunca lo hará.

No hay un pedido predeterminado explícito. Por razones obvias, si crea una nueva tabla, inserta algunas filas y hace un “select *” sin una cláusula “where”, (muy probablemente) devolverá las filas en el orden en que fueron insertadas.

Pero nunca deberías confiar en que ocurra una orden predeterminada. Si necesita un pedido específico, use una cláusula “ordenar por”. Por ejemplo, en las versiones de Oracle hasta 9i, hacer un “grupo por” también hacía que las filas se ordenaran por la expresión del grupo. En 10g, ¡este comportamiento ya no existe! La actualización de las instalaciones de Oracle me ha causado algo de trabajo debido a esto.

Ya se ha dicho que Oracle puede darle las filas en el orden que desee, cuando no especifica una cláusula ORDER BY. Especular cuál será el orden cuando no se especifica la cláusula ORDER BY no tiene sentido. Y confiar en su código es un “movimiento limitante de carrera”.

Un simple ejemplo:

 SQL> create table t as select level id from dual connect by level < = 10 2 / Tabel is aangemaakt. SQL> select id from t 2 / ID ---------- 1 2 3 4 5 6 7 8 9 10 10 rijen zijn geselecteerd. SQL> delete t where id = 6 2 / 1 rij is verwijderd. SQL> insert into t values (6) 2 / 1 rij is aangemakt. SQL> select id from t 2 / ID ---------- 1 2 3 4 5 7 8 9 10 6 10 rijen zijn geselecteerd. 

Y esto solo después de una simple eliminación + inserción. Y hay muchas otras situaciones pensables. Ejecución paralela, particiones, tablas organizadas por índice para nombrar solo algunas.

En pocas palabras, como ya dijo muy bien ammoQ: si necesita ordenar las filas, use una cláusula ORDER BY.

Absolutamente, no puedes confiar en ningún pedido a menos que especifiques el order by . Para Oracle en particular, he visto exactamente la misma consulta (sin uniones), corrí dos veces en pocos segundos el uno del otro, en una tabla que no cambió en el ínterin, devuelve un orden muy diferente. Esto parece ser más probable cuando el conjunto de resultados es grande.

La ejecución paralela mencionada por Rob van Wijk probablemente explica esto. Ver también Oracle usando el documento de ejecución paralela .

Puede modificar el orden en que se almacenan los datos en la tabla mediante INSERT con la cláusula ORGANIZATION de la sentencia CREATE TABLE

Se ve afectado por el índice, si hay un índice, devolverá un orden ascendente, si no hay ningún índice, devolverá el orden insertado.

Aunque debería ser rownnum (su número 2), realmente no está garantizado y no debe confiar en él al 100%.

Creo que usa el atributo Rownum oculto de Oracle.

Por lo tanto, probablemente su número 1 sea correcto, suponiendo que no se realizaron eliminaciones que podrían haber liberado rownums para su uso posterior.

EDITAR: Como han dicho otros, realmente no deberías confiar en esto, nunca. Además de eliminar, hay muchas condiciones diferentes que pueden afectar el comportamiento de clasificación predeterminado.