MySQL 3.23/4.0/4.1 和 5.1 状态：
如果您使用
GROUP BY[ forselect]，则输出行将根据列进行排序，GROUP BY就像您ORDER BY对相同的列使用an一样。？？？
但是，MySQL 5.5 声明：
GROUP BY在 MySQL 5.5 中依赖隐式排序已被弃用。要实现分组结果的特定排序顺序，最好使用显式ORDER BY子句。？？？
MySQL 中的“已弃用”究竟是什么意思？
隐式的行为是否group by仍然保证在 MySQL 5.5、5.6 和 5.7（当前最新版本）上工作，就像之前的每个版本一样？
是否ORDER BY NULL仍然需要从做不必要的排序停止MySQL的？
编辑（由里克詹姆斯）
这包括数据库问题：
GROUP BY，而不ORDER BYORDER BY NULLRic*_*mes 10
“弃用”的意思是“不要使用它；它将被删除/禁止/错误/损坏/等是一些未来的版本”。同时，它确实有效。
对于 MySQL 来说，这是一种缓慢而乏味的方式来更改会破坏许多程序的东西。没有人知道有多少人依赖GROUP BY确实有一种含蓄 ORDER BY。这个特殊的“功能”是对 Ansi 标准的扩展。我怀疑他们想更改 MySQL 有两个原因：
头脑简单的方法（想想 3.xx 版）GROUP BY是对行进行排序并遍历它们，收集 dups 和执行SUM()等等。而且，在单核机器的时代，这是非常合理的。结果自然会排序。但是......如果你想GROUP BY在一台 24 核机器上抛出一个，那么维护排序会变得非常混乱。所以（我猜），这是一种优化，将在GROUP BY不再执行隐式ORDER BY. 这可能会在 5.8 中发生（只是猜测）。
您仍然可以获得效果，但您必须ORDER BY使用相同的列/表达式列表明确说明。
在ORDER BY NULL（目前）在做什么大多数情况下，因为大多数情况下，发现它更有效地进行排序的GROUP BY。 ORDER BY NULL, 将来可能会被允许，但实际上是禁止操作；毕竟它会导致相同的结果。
其他不推荐使用的东西也有类似的逻辑。 CREATE TABLE (...) TYPE=MyISAM最终（经过一段时间的弃用）变成了CREATE TABLE (...) ENGINE=MyISAM. 这打破了一些导出/导入情况，但前提是您从一个非常旧的版本转移到一个新版本。 SHOW INNODB STATUS成为SHOW ENGINE INNODB STATUS，可能是为了更清晰地解析SHOW.
从 MySQL 5.5 开始，GROUP BY不再隐含地保证执行顺序。
是否
ORDER BY NULL仍然需要从做不必要的排序停止MySQL的？
两个 NULL 值在 GROUP BY 中被视为相等。
执行 an 时
ORDER BY，如果您执行 ORDER BY ... ASC 则首先显示 NULL 值，如果执行 ORDER BY ... DESC 则最后显示
同样的事情适用于 DISTINCT
由于ORDER BY NULL是升序并且order 的值为NULL，因此数据集之前的顺序ORDER BY NULL将与之后相同。
另一个可以强加或拒绝排序的外部问题是 InnoDB 存储引擎。我有一篇关于聚集索引有时如何妨碍将表强制为所需的物理索引顺序的旧帖子：MySQL InnoDB 排序问题。这里是一个甚至更好的职位（什么是记录MySQL中的SELECT语句的默认顺序？）由Laurynas Biveinis的存储引擎是如何影响排序。
多年来，开发人员一直依赖于隐式排序。如果您决定在每个次要版本上升级 MySQL，您就可以轻松摆脱困境。
为了说明这一点，请查看选项simple_binlog_gtid_recovery。它是在 MySQL 5.6.21 中引入的，以帮助 mysqld 遍历 binlogs 以进行 GTID 和崩溃恢复。你猜怎么着 ？？？两个小版本（MySQL 5.6.23）之后，Oracle 引入了binlog_gtid_simple_recovery。你不知道什么时候甲骨文将拉动地毯并除役simplified_binlog_gtid_recovery因使用。许多基础设施依赖于那个旧选项。所以，买家当心！！！
当然，这是一个很快被新名称取代的新选项。
现在，想象一下有多少依赖于隐式排序的应用程序受到 mysql 升级的影响。
因此，您应该始终在 Dev/Staging 服务器中测试代码以了解 SELECT 中的任何行为变化。此类测试无可替代。