使用DATE_FORMAT按小时分组需显式处理时区，否则因系统时区影响导致分组错误；统计增量须用LAG()等窗口函数计算差值，不可仅COUNT(*)；WHERE应置于分组前以保留空小时；函数操作会使索引失效，建议用生成列索引优化。
用 DATE_FORMAT 按小时分组必须显式指定时区或确认系统时区一致
MySQL 的 DATE_FORMAT 本身不转换时区，它只是格式化时间值。如果你的 created_at 是 DATETIME 类型且存的是 UTC 时间，但服务器时区设为 Asia/Shanghai，直接 DATE_FORMAT(created_at, '%Y-%m-%d %H') 会按本地时区解释该时间——导致“同一行数据在不同时区设置下分到不同小时桶”。实际统计前先查清：
SELECT @@time_zone, @@system_time_zone;若需统一按北京时间统计，稳妥做法是显式转换：
DATE_FORMAT(CONVERT_TZ(created_at, '+00:00', '+08:00'), '%Y-%m-%d %H')
统计增量不能只靠 COUNT(*)，得用窗口函数或自连接算差值
“每小时增量”本质是相邻小时记录数的差值，不是单纯计数。比如 10:00–10:59 有 120 条、11:00–11:59 有 135 条，增量是 15 条。纯 GROUP BY DATE_FORMAT(...) 只能拿到每小时总量，没前后关系。正确做法有两种：
- 用
LAG()窗口函数（MySQL 8.0+）：SELECT hour_bin, cnt - LAG(cnt) OVER (ORDER BY hour_bin) AS increment FROM (SELECT DATE_FORMAT(created_at, '%Y-%m-%d %H') AS hour_bin, COUNT(*) AS cnt FROM logs GROUP BY hour_bin) t;
- MySQL 5.7 及以下只能自连接或变量模拟，但要注意变量顺序依赖
ORDER BY，且无法保证稳定执行计划
WHERE 条件必须放在分组前，否则会漏掉空小时
如果只想看最近 24 小时的增量，别写成：
GROUP BY DATE_FORMAT(created_at, '%Y-%m-%d %H') HAVING hour_bin >= '2024-06-01 10'这会先分组再过滤，导致 24 小时内无数据的小时直接消失，无法识别“零增量”。正确方式是把时间范围压到
WHERE：WHERE created_at >= DATE_SUB(NOW(), INTERVAL 24 HOUR)如果还要补全空小时（比如显示每小时 0–100 的完整序列），就得用生成数字表或递归 CTE 补左连接，不是
DATE_FORMAT 本身能解决的。
索引失效常见于对 created_at 做函数操作
DATE_FORMAT(created_at, '%Y-%m-%d %H') 会让 created_at 上的索引完全失效，尤其在大表上可能全表扫描。优化方向有两个：
- 改用范围查询代替函数分组：先确定每小时起止时间，用
BETWEEN分段查，再拼结果（适合固定小时数场景） - 建生成列索引（MySQL 5.7+）：
ALTER TABLE logs ADD COLUMN hour_bin VARCHAR(13) GENERATED ALWAYS AS (DATE_FORMAT(created_at, '%Y-%m-%d %H')) STORED; CREATE INDEX idx_hour_bin ON logs(hour_bin);
这样WHERE hour_bin = '2024-06-01 14'就能走索引
真正麻烦的不是语法，而是增量定义是否包含软删除、是否去重、时间字段精度是否到秒级——这些都会让“每小时新增多少”变成一个业务逻辑问题，不是加个 DATE_FORMAT 就能答准的。
