且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

用 MySQL 分组时返回哪一行的字段?

更新时间:2023-02-13 20:41:01

将返回哪个 id(1、2 或 3)?

A:服务器将为所有具有相同名称的记录选择它想要的 id(很可能是获取最快的,这是不可预测的).引用官方文档:

A: The server will choose for all the records that have the same name the id it wants (most likely the fastest to fetch, which is unpredictable). To cite the official documentation:

服务器可以***地从每个组中选择任何值,因此除非它们相同,否则选择的值是不确定的.

The server is free to choose any value from each group, so unless they are the same, the values chosen are indeterminate.

链接中的更多信息.

该查询将哪个 id 转到 ORDER BY(与返回的相同?...请参阅问题 1)?

找出检索到的数据将按什么顺序返回是没有意义的,因为您无法预测将获得的结果.但是,您很可能会得到按不可预测的 ID 列排序的结果.

It makes no sense to find out in what order the data retrieved will be returned as you can't predict the result you are going to get. However, it is very likely that you get the result sorted by the unpredictable ID column.

您能控制返回/用于订购的 ID 吗?例如.返回最大的 id,或来自 GROUP 的第一个 id.

此时您应该假设您不能.再次阅读文档.

You should be assuming at this point that you can't. Read again the documentation.

让事情更清楚:您无法预测不当使用 GROUP BY 子句的结果.MySQL 的主要问题是它允许您以非标准方式使用它,但您需要知道如何使用该功能.其背后的要点是按您知道将始终相同的字段分组.EG:

Making things even more clear: You can't predict the result of an improperly used GROUP BY clause. The main issue with MySQL is that it allows you to use it in a non-standard way but you need to know how to make use of that feature. The main point behind it is to group by fields that you know will always be the same. EG:

SELECT id, name, COUNT( * ) AS frequency
FROM table
GROUP BY id

在这里,您知道 name 将是唯一的,因为 id 在功能上决定了 name.所以你知道的结果是有效的.如果你也按名称分组,这个查询会更标准,但在 MySQL 中的表现会稍微差一些.

Here, you know name will be unique as id functionally determines name. So the result you know is valid. If you grouped also by name this query would be more standard but will perform slightly worse in MySQL.

最后要注意的是,根据我的经验,对于选定和非分组字段的那些非标准查询的结果通常是应用GROUP BY后得到的结果> 然后是该字段上的 ORDER BY.这就是为什么它多次似乎起作用的原因.但是,如果您继续测试,您最终会发现这种情况的发生率为 95%.你不能依赖那个数字.

As a final note, take into account that, in my experience the results in those non-standard queries for the selected and non-grouped fields are usually the ones that you would get applying a GROUP BY and then an ORDER BY on that field. That is why so many times it seems to work. However, if you keep testing you will eventually find out that this happens 95% of the time. And you can not rely on that number.