Ne, na takové chování se nelze spolehnout. Pořadí je určeno způsobem, jakým se plánovač dotazů rozhodl sestavit sadu výsledků. jednoduché dotazy jako select * from foo_table se pravděpodobně vrátí v pořadí, v jakém jsou uloženy na disku, což může být pořadí primárního klíče nebo pořadí, v jakém byly vytvořeny, nebo nějaké jiné náhodné pořadí. složitější dotazy, jako je select * from foo where bar < 10 může být místo toho vrácen v pořadí jiného sloupce na základě přečteného indexu nebo podle pořadí tabulky pro skenování tabulky. ještě propracovanější dotazy s vícenásobným where podmínky, group by klauzule, union s, bude v jakémkoli pořadí, o kterém plánovač rozhodne, že je nejúčinnější generovat.
Pořadí se dokonce mohlo změnit mezi dvěma identickými dotazy jen kvůli datům, která se mezi těmito dotazy změnila. klauzule "kde" může být spokojena se skenováním indexu v jednom dotazu, ale pozdější vložení by mohlo učinit tuto podmínku méně selektivní a plánovač by se mohl rozhodnout provést následný dotaz pomocí skenování tabulky.
Abych tomu dal jemnější pointu. Systémy RDBMS mají mandát vám poskytnout přesně co jste požadovali, co nejefektivněji. Tato efektivita může mít mnoho podob, včetně minimalizace IO (jak na disk, tak přes síť, aby vám mohla posílat data), minimalizace CPU a udržování malé velikosti jeho pracovní sady (pomocí metod, které vyžadují minimální dočasné úložiště).
bez ORDER BY klauzule, nebudete se ptát přesně pro konkrétní objednávku, a tak vám RDBMS poskytne tyto řádky v nějakém pořadí, které (možná) odpovídá nějakému náhodnému aspektu dotazu, na základě kteréhokoli algoritmu, který RDBMS očekává, že vytvoří data nejrychleji.
Pokud vám záleží na efektivitě, ale ne na objednávce, přeskočte ORDER BY doložka. Pokud vám záleží na objednávce, ale ne na efektivitě, použijte ORDER BY doložka.
Protože vám ve skutečnosti záleží na OBOU použijte ORDER BY a poté pečlivě vylaďte svůj dotaz a databázi tak, aby byly efektivní.