时间字段必须是datetime或timestamp类型，字符串需先用STR_TO_DATE等显式转换；按小时分组应结合日期与小时（如DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00')），避免仅用HOUR()导致跨日聚合；WHERE条件须含可走索引的时间范围，禁用函数包裹字段。

时间字段必须是 datetime 或 timestamp 类型

如果 created_at 是字符串（比如 '2024-05-20 14:30:22'），直接用 HOUR() 或 DATE_FORMAT() 可能返回 NULL 或意外结果。MySQL 会尝试隐式转换，但一旦格式不标准（如带毫秒、时区偏移、空格不一致），就统计不准。

实操建议：

• 先确认字段类型：DESCRIBE api_logs;，看 created_at 列的 Type 是否为 datetime 或 timestamp
• 如果是字符串，优先在写入时转成 datetime；临时补救可用：STR_TO_DATE(created_at, '%Y-%m-%d %H:%i:%s')（需严格匹配格式）
• 避免用 SUBSTRING(created_at, 12, 2) 截取小时——它不校验合法性，'2024-05-20 25:00:00' 也会被算作 25 点

按小时分组要兼顾日期和小时

只用 HOUR(created_at) 分组，会把所有天的 14 点合并成一条，失去时间维度。真实场景中，你需要知道“2024-05-20 14:00–14:59 有多少请求”，而不是“所有日子的 14 点加起来多少”。

正确做法是用 DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00') 或 DATE(created_at) + HOUR(created_at) 组合：

SELECT 
  DATE_FORMAT(created_at, '%Y-%m-%d %H:00:00') AS hour_start,
  COUNT(*) AS req_count
FROM api_logs 
WHERE created_at >= '2024-05-20' 
GROUP BY hour_start
ORDER BY hour_start;

注意：DATE_FORMAT(..., '%Y-%m-%d %H:00:00') 生成的是每小时整点时间戳，便于对齐和后续图表展示；若用 DATE(created_at), HOUR(created_at) 作为 GROUP BY 字段，则结果里得显式 SELECT 这两个字段，否则 MySQL 8.0+ 会报错（ONLY_FULL_GROUP_BY 模式下）。

WHERE 条件必须加时间范围索引支持

没加 WHERE created_at >= ... 的全表扫描，哪怕只有 100 万行，按小时聚合也极慢。更糟的是，如果只加 HOUR(created_at) = 14 而不带日期过滤，MySQL 无法使用 created_at 索引（因为函数导致索引失效）。

确保高效执行：

• WHERE 中必须包含可走索引的时间范围，例如：created_at BETWEEN '2024-05-20 00:00:00' AND '2024-05-21 23:59:59'
• 避免写成：HOUR(created_at) = 14 AND DATE(created_at) = '2024-05-20' —— 这两个函数都会让索引失效
• 如果查询频繁且固定按小时分析，可考虑建组合索引：INDEX idx_time_req (created_at, status)（status 是常见过滤字段）

注意时区和日志写入时间一致性

数据库服务器时区（SELECT @@time_zone;）、应用写入时使用的时区、以及你期望统计的业务时区（比如东八区）三者不一致，会导致同一小时段数据被拆到相邻两小时里。

典型问题：

• 应用用 UTC 写入，DB 用 CST，查出来的 “2024-05-20 14:00” 实际对应北京时间 22:00
• 前端展示按本地时间渲染，但后端统计没统一转换，图表出现“断层”或“双峰”
• 解决方案不是改 DB 时区（影响大），而是：写入时明确用 CONVERT_TZ(NOW(), '+00:00', '+08:00') 或应用层统一转为 UTC 存储，查的时候再转回业务时区

真正麻烦的不是语法，是时间源是否可信——日志时间戳来自 NTP 同步的服务器？还是客户端传的？后者基本不可用于精确小时统计。