使用count()时ORDER BY为何失效？求原因及解决办法

这是个典型的聚合函数与排序结合时的常见误区，我来帮你拆解问题并给出修复方案：

问题原因 #

你的SQL语句存在一个关键逻辑漏洞：使用了聚合函数count(1)但未指定GROUP BY子句，同时试图直接选取非聚合列date_time。

在多数数据库（比如MySQL的非严格模式下），这种写法不会直接报错，但数据库的执行逻辑和你预期的完全不同：

1. 先筛选出所有符合user_id = :id的行；
2. 因为没有GROUP BY，所有筛选后的行会被合并成一个单一的聚合组；
3. count(1)会正确计算这个组的总行数，但date_time会从组内的任意一行中随机选取一个值（并非你以为的排序后第一行的值）；
4. 后续的ORDER BY date_time DESC LIMIT 1其实是对这个单一聚合组进行排序（毫无意义），最终返回的date_time只是刚好随机选中了1517045060而已。

修复方案 #

根据你的需求（获取该用户的总请求数 + 最新的date_time），有两种高效的修复方式：

方案一：使用聚合函数直接获取最大值（推荐） #

直接用MAX(date_time)来获取最新的时间戳，同时统计总数，这是最符合SQL标准且性能最优的写法：

SELECT 
  COUNT(1) AS all_requests_num,
  MAX(date_time) AS date_time
FROM requests 
WHERE user_id = :id;

执行这个语句后，会直接返回该用户的总请求数，以及最大的date_time（也就是你预期的1517045063），不需要额外的ORDER BY和LIMIT。

方案二：子查询先排序再聚合（适合特殊场景） #

如果因为某些业务场景限制你需要先排序再处理，可以用子查询先拿到排序后的结果，再聚合：

SELECT 
  COUNT(1) AS all_requests_num,
  date_time
FROM (
  -- 先筛选并排序，确保最新的date_time在结果集第一行
  SELECT date_time 
  FROM requests 
  WHERE user_id = :id 
  ORDER BY date_time DESC
) AS sorted_requests
LIMIT 1;

不过这种写法的性能不如方案一，因为子查询需要先排序所有符合条件的行，所以优先推荐方案一。

额外注意 #

如果你的数据库开启了严格模式（比如MySQL的ONLY_FULL_GROUP_BY参数），你原来的SQL语句会直接抛出错误——这其实是好事，因为SQL标准要求：SELECT列表中的非聚合列必须出现在GROUP BY子句中。开启严格模式能帮你提前发现这类逻辑错误，建议保持开启。

用你提供的示例表测试，假设所有行的user_id都是:id指定的值，执行方案一的SQL会得到：

+----------------+-------------+
| all_requests_num | date_time |
+----------------+-------------+
| 4              | 1517045063 |
+----------------+-------------+

完全符合你的预期。

内容的提问来源于stack exchange，提问作者Martin AJ