mysql - 聚合函数什么时候需要 GROUP BY？

Question

我有一个名为 myEntity 的表，如下所示:

- id (PK INT NOT NULL)
- account_id (FK INT NOT NULL)
- key (INT NOT NULL.  UNIQUE for given account_id)
- name (VARCHAR NOT NULL.  UNIQUE FOR given account_id)

我不想向用户公开主键id，为此添加了key。 key 类似于给定 accounts_id 的自动增量列，需要由应用程序手动完成。我首先计划制作主键复合 id-account_id，但是，该表已连接到其他表，并且在我知道之前，我在一个表中有四列，本来可以是一列。虽然 account_id-name 与 account_id-key 的作用相同，但 key 更小，并且在客户端请求多条记录时将网络流量降至最低。是的，我知道它没有正确规范化，虽然这不是我的直接问题，但如果有任何建设性的批评意见，我将不胜感激。

对不起，乱七八糟的……聚合函数什么时候需要 GROUP BY？例如，以下情况如何？ https://stackoverflow.com/a/1547128/1032531没有显示一个。有必要吗？

SELECT COALESCE(MAX(key),0)+1 FROM myEntity WHERE accounts_id=123;

Answer 1

您举了一个不需要 GROUP BY 的查询作为示例。为了便于说明，我将其简化如下。

SELECT MAX(key)
  FROM myEntity
 WHERE accounts_id = 123

为什么该查询不需要 GROUP BY？因为您只希望结果集中有一行描述特定的帐户。

如果您想要一个描述所有帐户的结果集，每个帐户一行怎么办？然后你会使用这个:

 SELECT accounts_id, MAX(key)
   FROM myEntity
  GROUP BY accounts_id

看看进展如何？对于 accounts_id 的每个不同值，您会在此结果集中获得一行。顺便说一下，MySQL 的查询规划器知道

 SELECT accounts_id, MAX(key)
   FROM myEntity
  WHERE accounts_id = '123'
  GROUP BY accounts_id

等同于省略 GROUP BY 子句的相同查询。

还有一点要知道:如果您的表中有一个关于 (accounts_id, key) 的复合索引，所有这些查询都将几乎奇迹般地快，因为查询计划器将以非常高效loose index scan.这特定于 MAX() 和 MIN() 聚合函数。松散索引扫描不能用于 SUM() 或 AVG() 或类似函数；那些需要严格的索引扫描。