Rah*_*hul 49
没有这样的订单.取自http://forums.mysql.com/read.php?21,239471,239688#msg-239688
如果缺少ORDER BY,请不要依赖订单.
如果您想要特定订单,请始终指定ORDER BY - 在某些情况下,引擎可以消除ORDER BY,因为它执行其他步骤.
- GROUP BY强制ORDER BY.(这违反了标准.使用ORDER BY NULL可以避免这种情况.)
SELECT * FROM tbl- 这将进行"表扫描".如果表从未有任何DELETE/REPLACEs/UPDATE,则记录将恰好处于插入顺序中,因此您观察到的是.如果您使用InnoDB表执行了相同的语句,则它们将以PRIMARY KEY顺序而非INSERT顺序传递.同样,这是底层实现的工件,而不是依赖的东西.
alf*_*alf 19
没有.根据您查询的内容以及查询的优化方式,您可以获得任何订单.甚至不能保证看起来相同的两个查询将以相同的顺序返回结果:如果您没有指定它,则不能依赖它.
我发现 SQL Server 的默认顺序几乎是随机的（取决于数据的年龄和复杂性），这很好，因为它强制您指定所有顺序。
（我依稀记得 Oracle 在这方面类似于 SQL Server。）
默认情况下，MySQL 似乎按磁盘上的记录结构排序（可能包括由于删除和优化而导致的乱序条目），但它最初常常愚弄开发人员不费心使用 order-by 子句，因为数据似乎默认为主键排序，事实并非如此！
我今天惊讶地发现，MySQL 5.6 和 4.1 隐式地对已在相反方向上有限分辨率的列上排序的记录进行排序。我的一些结果具有相同的排序值，并且整体顺序是不可预测的。例如，在我的情况下，它是按日期时间列排序的 DESC，并且某些条目在同一秒内，因此无法明确排序。在 MySQL 5.6 上，它们按一种顺序（插入顺序）进行选择，但在 4.1 中，它们向后选择！这导致了一个非常烦人的部署错误。
我没有找到有关此更改的文档，但找到了有关MySQL 中隐式组顺序的说明：
默认情况下，MySQL 对所有 GROUP BY col1, col2, ... 查询进行排序，就像您在查询中指定 ORDER BY col1, col2, ... 一样。
然而：
在 MySQL 5.5 中依赖隐式 GROUP BY 排序已被弃用。要实现分组结果的特定排序顺序，最好使用显式 ORDER BY 子句。
因此，与其他答案一致-永远不要依赖任何数据库中的默认或隐式排序。