Ordre de ligne par défaut pour la requête select dans oracle
dans Oracle, Quel est l'ordre par défaut des lignes pour une requête select si aucune clause "ordre par" n'est spécifiée.
Est-ce
- l'ordre dans lequel les lignes ont été insérées
- il n'y a pas d'ordre par défaut
- aucune de ces réponses.
8 réponses
selon Tom Kyte: "à moins et jusqu'à ce que vous ajoutiez" ordre Par " à une requête, vous ne pouvez rien dire sur l'ordre des lignes retournées. Ainsi, à court de "vous ne pouvez pas compter sur l'ordre des lignes retourné'."
Voir cette question à asktom.com.
quant à ROWNUM, il n'existe pas physiquement, donc il ne peut pas être "libéré". ROWNUM est assignée après qu'un enregistrement est récupéré à partir d'une table, ce qui est pourquoi "où ROWNUM = 5" ne sera toujours pas sélectionner dossier.
@ammoQ: vous voudrez peut-être lire c'AskTom article sur le GROUPE PAR la commande. En bref:
fait un groupe par clause dans une requête gaurantee que les données de sortie seront triés sur le groupe par colonnes en l'ordre, même S'il N'y a pas D'ordre de clause?
et nous l'avons dit...
ABSOLUMENT PAS,
Il n'a jamais, il n'a jamais, jamais sera.
il n'y a pas d'ordre explicite par défaut. Pour des raisons évidentes, si vous créez une nouvelle table, insérez quelques lignes et faites un "select *" sans une clause "where", cela retournera (très probablement) les lignes dans l'ordre où elles ont été insérées.
mais vous ne devriez jamais compter sur une commande par défaut. Si vous avez besoin d'une commande spécifique, utilisez une clause "ordre par". Par exemple, dans les versions d'Oracle jusqu'à 9i, faire un "groupe" a également causé les lignes triées par l'expression de groupe. En 10g, ce le comportement n'existe plus! La mise à niveau des installations Oracle m'a causé du travail à cause de cela.
il a déjà été dit Qu'Oracle est autorisé à vous donner les lignes dans n'importe quel ordre qu'il veut, quand vous ne spécifiez pas une commande par clause. Spéculer sur ce que sera l'ordre quand vous ne spécifiez pas l'ordre Par clause est inutile. Et s'y fier dans votre code, c'est un"mouvement limitant la carrière".
Un exemple simple:
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 aangemaakt.
SQL> select id from t
2 /
ID
----------
1
2
3
4
5
7
8
9
10
6
10 rijen zijn geselecteerd.
et ce n'est qu'après une simple suppression+insertion. Et il y a de nombreuses autres situations qui sont concevables. Exécution parallèle, partitions, index tables organisées pour n'en nommer que quelques-unes.
conclusion, comme déjà très bien dit par ammoQ: si vous avez besoin de trier les lignes, utilisez un ordre Par clause.
Vous absolument, positivement ne pouvez compter sur aucune commande à moins que vous spécifiez order by. Pour Oracle en particulier, j'ai effectivement vu la même requête exacte (sans jointures), exécuter deux fois en quelques secondes l'un de l'autre, sur une table qui n'a pas changé entre-temps, retourner un ordre très différent. Cela semble être plus probable lorsque le jeu de résultats est grande.
l'exécution parallèle mentionnée par Rob van Wijk explique probablement ceci. Voir Aussi Oracle En Utilisant En Parallèle Exécution doc.
vous pouvez modifier l'ordre dans lequel les données sont stockées dans la table en insérant la clause D'organisation de L'instruction CREATE TABLE
elle est affectée par l'index , s'il y a index, il retournera un ordre ascendant , s'il n'existe aucun indice ,il sera de retour l'ordre inséré .
bien que, il devrait être rownnum (votre #2), Il n'est vraiment pas garanti et vous ne devriez pas lui faire confiance à 100%.
je crois qu'il utilise L'attribut Rownum caché D'Oracle.
donc votre #1 est probablement juste en supposant qu'il n'y ait pas eu de suppression qui aurait pu libérer rownums pour une utilisation ultérieure.
EDIT: Comme d'autres l'ont dit, vous ne devriez pas compter sur cette, jamais. En plus de supprimer il y a beaucoup de conditions différentes qui peuvent affecter le comportement de tri par défaut.