hour()函数返回时间值的小时部分（0–23），仅提取“时”字段，不四舍五入、不转时区、不受日期影响；需确保输入为时间类型，否则跨数据库可能报错。
SQL中HOUR()函数到底返回什么时间部分
HOUR() 函数只提取时间值（TIMESTAMP、DATETIME 或 TIME 类型）的小时数，范围是 0 到 23，不四舍五入、不转换时区、也不受日期影响。它只看“时”这一字段——比如 '2024-05-12 14:38:02' 返回 14，'03:59:59' 返回 3。
常见错误是传入字符串但没转成时间类型，比如直接写 HOUR('14:30')：在 MySQL 中可能侥幸成功（隐式转换），但在 PostgreSQL 或 SQL Server 中会报错 function hour(unknown) does not exist 或类似提示。
- 务必确保字段或表达式是时间类型，必要时用
CAST(created_at AS TIME)或TIME(created_at) - MySQL 支持
HOUR(NOW())，但 SQLite 没有HOUR()，得用strftime('%H', created_at) - 如果字段是字符串（如
'2024/05/12 14:30'），先用STR_TO_DATE()（MySQL）或TO_TIMESTAMP()（PostgreSQL）转再取小时
按小时统计访问量的典型写法
核心是把原始时间字段用 HOUR() 提取小时，再配合 GROUP BY 和 COUNT(*)。注意别漏掉 WHERE 过滤有效时间——空值或非法时间会导致 HOUR() 返回 NULL，进而让整行被排除在分组外。
示例（MySQL）：
SELECT HOUR(created_at) AS hour_of_day, COUNT(*) AS visit_count FROM access_log WHERE created_at IS NOT NULL AND created_at >= '2024-05-01' GROUP BY HOUR(created_at) ORDER BY hour_of_day;
- 结果中
hour_of_day是0～23的整数，不是带前导零的字符串（如不会是'09'） - 如果想补零显示（比如用于图表横轴对齐），可套一层
LPAD(HOUR(created_at), 2, '0') - 若要区分工作日/周末的小时趋势，需额外提取星期几（如
WEEKDAY(created_at)），不能只靠HOUR()
HOUR() 在跨天聚合时的陷阱
HOUR() 本身不感知日期，所以单纯按小时分组会把所有日期的 14 点合并在一起。这在分析“每天 14 点访问最多”时有用，但若想看“过去 24 小时内每小时流量”，就不能只用 HOUR() —— 它无法区分今天 14:00 和昨天 14:00。
- 真正滚动 24 小时统计，应使用时间范围过滤：
WHERE created_at >= NOW() - INTERVAL 24 HOUR，再按HOUR(created_at)分组 - 若需精确到小时粒度的时间序列（含空缺小时补 0），
HOUR()无法直接生成完整 0–23 序列，得用递归 CTE 或临时数字表 LEFT JOIN - 时区问题常被忽略：数据库服务器时区、应用写入时区、查询会话时区不一致时，
HOUR(created_at)可能和业务预期差几小时
替代方案：什么时候不该用 HOUR()
当原始数据只有日期没有时间（如 DATE 类型字段），HOUR() 恒返回 0，毫无意义；当需要按“上午/下午”粗粒度划分，硬用 HOUR() IN (0,1,2...11) 不如直接用 EXTRACT(HOUR FROM created_at)（标准 SQL）或条件表达式更清晰。
- PostgreSQL 推荐用
EXTRACT(HOUR FROM created_at)，兼容性更好，且明确支持TIMESTAMP WITH TIME ZONE - BigQuery 中用
EXTRACT(HOUR FROM created_at)，不支持HOUR() - 如果要做小时级同比（比如今天 14 点 vs 昨天 14 点），重点在时间对齐逻辑，
HOUR()只是中间一步，主逻辑得靠DATE_SUB(created_at, INTERVAL 1 DAY)这类操作
真正卡住人的往往不是函数怎么写，而是没想清楚“小时”在这里代表的是钟表时间点、还是业务时段切片、还是滚动窗口——HOUR() 只负责拆解，剩下的得靠上下文定。
