SUBSTRING提取小时仅适用于格式统一的字符串时间，易因单数字小时或非法格式出错；推荐用DATE_PART或EXTRACT等时间函数，先确保字段为时间类型再处理，避免脏数据。
用 SUBSTRING 提取小时字段只适用于字符串型时间，且依赖固定格式
当你的时间字段是 TEXT 或 VARCHAR 类型（比如 '2024-05-20 14:32:17'），SUBSTRING 确实能快速切出小时部分，但必须确保格式统一、无空格或时区干扰。常见错误是直接写 SUBSTRING(time_str, 12, 2) —— 这在 '2024-05-20 9:32:17'（单数字小时）下会截到冒号，结果变成 '9:'。
安全做法是先转成标准时间类型再处理，或者用带分隔符定位的方式：
SELECT SUBSTRING(time_str FROM POSITION(' ' IN time_str) + 1 FOR 2) AS hour, COUNT(*)
FROM logs
GROUP BY hour;
但更推荐避免这种字符串操作：一旦日志里混入 '2024-05-20T14:32:17Z' 或毫秒级 '2024-05-20 14:32:17.123'，SUBSTRING 就会批量出错。
DATE_PART('hour', ...) 是 PostgreSQL 的标准解法，但其他数据库不兼容
DATE_PART('hour', created_at) 在 PostgreSQL 中稳定可靠，自动处理时区（取决于 created_at 类型和 session timezone），且不关心输入是否带毫秒或时区后缀。
注意几个关键点：
-
created_at必须是TIMESTAMP WITH TIME ZONE或WITHOUT TIME ZONE；如果是TEXT，得先用TO_TIMESTAMP()转换，否则报错function date_part(unknown, text) does not exist - 想按本地时区统计？确保列类型为
TIMESTAMPTZ，并设置SET TIME ZONE 'Asia/Shanghai'; - MySQL 和 SQL Server 没有
DATE_PART，对应的是HOUR(created_at)和DATEPART(HOUR, created_at)—— 别在跨库项目里硬搬函数名
按自然小时聚合（如 14:00–14:59）不能只靠截小时数
单纯提取小时值（如 14）只能归并同一小时内的所有记录，看似合理，但容易掩盖数据倾斜问题：如果某条记录时间是 '2024-05-20 14:59:59.999'，它属于 14 点；而 '2024-05-20 15:00:00' 就算进 15 点——这没问题。但如果你的原始数据是字符串且未标准化，可能把 '2024-05-20 14:60:00'（非法时间）也塞进来，DATE_PART 会报错，SUBSTRING 却照常返回 '14'，导致脏数据被计入。
真正健壮的写法是先过滤再分组：
SELECT EXTRACT(HOUR FROM created_at) AS hour, COUNT(*) FROM logs WHERE created_at >= '2024-05-20'::DATE AND created_at < '2024-05-21'::DATE AND created_at IS NOT NULL GROUP BY hour ORDER BY hour;
这里用 EXTRACT（SQL 标准函数，PostgreSQL/MySQL/Oracle 都支持）替代 DATE_PART，提高可移植性；同时加了非空和范围约束，避免隐式转换失败或索引失效。
性能差异大：函数包裹字段会让索引失效，需提前物化小时字段
在千万级访问日志表上，GROUP BY DATE_PART('hour', created_at) 几乎必然触发全表扫描，因为 created_at 上的 B-tree 索引无法用于函数计算后的值。
两种实际可用的优化路径：
- 建表达式索引：
CREATE INDEX idx_logs_hour ON logs (EXTRACT(HOUR FROM created_at));（PostgreSQL 支持，MySQL 8.0+ 也支持函数索引） - 新增冗余字段
hour_of_day SMALLINT，写入时用触发器或应用层计算并存储，查询直接GROUP BY hour_of_day，稳定高效 - 避免在
WHERE子句中对时间字段用函数，比如WHERE DATE_PART('hour', created_at) = 14，应改写为WHERE created_at >= '2024-05-20 14:00:00' AND created_at
时间字段上的函数调用，看着只是多敲几个字母，实际可能让查询从 50ms 拉长到 12s——这点在看监控图表时特别容易被忽略。
