错误源于MySQL 5.7+默认启用ONLY_FULL_GROUP_BY模式，WHERE中使用HOUR()被判定为非确定性表达式；解决方法包括确保created_at为DATETIME/TIMESTAMP类型、SELECT与GROUP BY中统一使用HOUR(created_at)，或改用HAVING过滤、WHERE中用时间范围替代HOUR()函数。
MySQL中用HOUR()函数分组报错：Invalid use of group function
直接在GROUP BY里写HOUR(created_at)通常没问题，但一旦你同时写了WHERE HOUR(created_at) > 8又想按小时分组，就可能触发这个错误——本质是MySQL 5.7+默认启用了ONLY_FULL_GROUP_BY模式，而HOUR()在WHERE里被当成“非确定性表达式”参与了隐式分组判断。
解决方法很简单：
- 确认字段本身是
DATETIME或TIMESTAMP类型，别用VARCHAR存时间（否则HOUR()返回NULL） - 把
HOUR()提取到SELECT和GROUP BY中保持一致，例如：SELECT HOUR(created_at) AS hour_of_day, COUNT(*) FROM orders GROUP BY HOUR(created_at);
- 如果要过滤特定小时段，用
HAVING代替WHERE（适用于聚合后筛选），或把条件移到WHERE但不依赖HOUR()，比如：WHERE created_at >= '2024-01-01 09:00:00' AND created_at
PostgreSQL里没有HOUR()函数，怎么按小时统计？
PostgreSQL用EXTRACT()替代，语法更明确，也更安全：
SELECT EXTRACT(HOUR FROM created_at) AS hour_of_day, COUNT(*) FROM orders GROUP BY EXTRACT(HOUR FROM created_at) ORDER BY hour_of_day;
注意点：
-
EXTRACT(HOUR FROM ...)返回double precision，分组时最好显式转成整数：EXTRACT(HOUR FROM created_at)::int - 如果
created_at带时区（如timestamptz），EXTRACT默认按当前会话时区计算——需要统一时区时，先用AT TIME ZONE 'Asia/Shanghai'转换 - 不能用
HOUR(created_at)，那会直接报错function hour(timestamp without time zone) does not exist
跨天的小时段统计（比如早8点到次日早8点）怎么写？
单纯用HOUR()或EXTRACT(HOUR...)只能按自然小时（0–23）切片，无法表达“滚动24小时”。这时候得构造一个逻辑偏移量：
以MySQL为例，把每天的统计起点设为早8点，可这样算“相对小时”：
SELECT FLOOR((UNIX_TIMESTAMP(created_at) - UNIX_TIMESTAMP(DATE(created_at)) + 8*3600) / 3600) % 24 AS segment_hour, COUNT(*) FROM orders GROUP BY segment_hour;
更可读的做法是用日期运算：
- 先减去8小时：
DATE_SUB(created_at, INTERVAL 8 HOUR) - 再取该偏移后日期的小时：
HOUR(DATE_SUB(created_at, INTERVAL 8 HOUR)) - 最终分组语句：
GROUP BY HOUR(DATE_SUB(created_at, INTERVAL 8 HOUR))
这样0就代表“当日早8点至9点”，1代表“9–10点”，…，23代表“次日7–8点”。
性能隐患：在WHERE或GROUP BY里对时间字段用函数会失效索引
这是最容易被忽略的一点。哪怕你加了INDEX(created_at)，只要写WHERE HOUR(created_at) = 14，MySQL就无法使用该索引——因为函数改变了原始列值，优化器没法做范围匹配。
正确做法是把函数操作“外推”成范围条件：
- 错的：
WHERE HOUR(created_at) = 14 - 对的：
WHERE created_at >= '2024-01-01 14:00:00' AND created_at （配合日期范围缩小） - 或者用生成列+索引（MySQL 5.7+）：
ALTER TABLE orders ADD COLUMN hour_of_created TINYINT GENERATED ALWAYS AS (HOUR(created_at)) STORED;<br>CREATE INDEX idx_hour ON orders(hour_of_created);
生成列方案适合固定按小时分析的场景，但要注意存储开销和写入性能影响。
