省略order子句的mysql Innodb查询的“默认Order”是什么？

Question

因此，我理解并找到了一些帖子，表明在从DBMS检索数据时不建议省略SQL查询中的order子句。

参考资料和职位咨询(将更新)：

SQL Server UNION - What is the default ORDER BY Behaviour

When no 'Order by' is specified, what order does a query choose for your record set?

https://dba.stackexchange.com/questions/6051/what-is-the-default-order-of-records-for-a-select-statement-in-mysql

问题:

如果您想知道更多的话，请参阅下面问题的逻辑。

我的问题是:在mysql和innoDB引擎下，有人知道数据库管理系统如何有效地给出结果吗？

我读到它是依赖于实现的，好吗，但是对于我当前的实现，有什么方法可以知道吗？

这究竟是在哪里定义的？

是MySQL，InnoDB，操作系统依赖的吗？

外面不是有什么名单吗？

最重要的是，如果我省略order子句并得到我的结果，我无法确定这段代码是否仍然适用于较新的数据库版本，而且DBMS将永远不会给出相同的结果，对吗？

用例与逻辑:

我目前正在编写一个CRUD API，我的DB中有一个不包含"id“字段的表(尽管有一个PK )，所以当我在没有任何研究标准的情况下显示该表的结果时，我真的不知道我应该使用什么来排序结果。我的意思是，我可以使用PK或任何从未为空的字段，但它不会使它相关。所以我想知道，因为我的CRUD应该适用于任何一个表，而且我不想通过为这个特定的表添加一个异常来解决这个问题，所以我也可以简单地省略order子句。

最后注:

当我阅读其他文章、例子和代码示例时，我觉得我想走得太远了。我了解到，众所周知，在请求中省略Order子句是一种错误的做法，而且没有可靠的缺省order子句，除非您指定，否则根本没有订单。

我只想知道它是在哪里定义的，我很想了解它是如何在内部工作的，或者至少是在哪里定义的(DBMS / Storage /OS-依赖/其他/多个标准)。我认为，了解这一点，了解当地的内部机制，也会对其他人有益。

无论如何，谢谢你抽出时间阅读！祝您今天愉快。

Answer 1

如果没有明确的ORDER BY，当前版本的InnoDB将按照读取索引的顺序返回行。哪个索引不同，但它总是从某些索引中读取。甚至从“表”中读取数据也是一个真正的索引--它是主要的关键索引。

与上面的注释一样，不能保证在下一个版本的InnoDB中保持不变。你应该把它当作一种巧合行为，它没有被记录下来，而且MySQL的制造者不承诺不改变它。

即使它们的实现没有改变，按索引顺序读取也会产生一些您可能不期望的奇怪效果，这不会给您提供对您有意义的查询结果集。

例如，默认索引是聚集索引(主索引)。这意味着索引顺序与主键中值的顺序相同(而不是插入它们的顺序)。

mysql> create table mytable ( id int primary key, name varchar(20));

mysql> insert into mytable values (3, 'Hermione'), (2, 'Ron'), (1, 'Harry');

mysql> select * from mytable;
+----+----------+
| id | name     |
+----+----------+
|  1 | Harry    |
|  2 | Ron      |
|  3 | Hermione |
+----+----------+

但是，如果您的查询使用另一个索引来读取表，就像您只访问辅助索引的列一样，您将按该顺序得到行：

mysql> alter table mytable add key (name);

mysql> select name from mytable;
+----------+
| name     |
+----------+
| Harry    |
| Hermione |
| Ron      |
+----------+

这表明它使用name上的辅助索引索引扫描来读取表

mysql> explain select name from mytable;
+----+-------------+---------+-------+---------------+------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | mytable | index | NULL          | name | 83      | NULL |    3 | Using index |
+----+-------------+---------+-------+---------------+------+---------+------+------+-------------+

在更复杂的查询中，预测InnoDB将用于给定查询的索引可能变得非常棘手。随着数据的变化，这种选择甚至可以日复一日地发生变化。

所有这些都表明:如果您关心查询结果集的顺序，应该只使用ORDER BY！

Answer 2

比尔的回答很好。但不完整。

• 如果查询是一个UNION，它将(我认为)首先传递第一个SELECT的结果(根据规则)，然后再传递第二个SELECT的结果。另外，如果表是PARTITIONed，则可能会做类似的事情。
• GROUP BY可以根据分组表达式进行排序，从而导致可预测的顺序，或者使用哈希技术对行进行置乱。我不知道该怎么预测。
• 派生表过去是一个有序列表，传播到父查询的排序中。但是最近，ORDER BY被丢弃在子查询中！(除非有LIMIT。)

：如果您关心订单，添加一个ORDER BY，即使基于这个Q& A似乎没有必要。

相反，MyISAM从以下前提开始:默认顺序是.MYD文件中的顺序。但是DELETEs留下了空白，UPDATEs处理了空白，而INSERTs更喜欢在文件后面填充空白。因此，行顺序是相当不可预测的。ALTER TABLE x ORDER BY y暂时设置.MYD顺序；此“特性”不适用于InnoDB。