按小时计算平均通话时长需先用数据库特有函数（如PostgreSQL的DATE_TRUNC、MySQL的DATE_FORMAT、SQLite的strftime）将时间戳对齐到小时粒度，再对数值型call_duration_sec取AVG；须过滤NULL、测试呼叫、异常值（0秒或>1800秒）及时区错位问题。
用 AVG() 配合 DATE_TRUNC() 或 EXTRACT() 按小时分组
核心是把通话时间戳对齐到小时粒度，再套 AVG()。不同数据库语法差异大，别直接抄示例——PostgreSQL 用 DATE_TRUNC('hour', call_start_time) 最干净；MySQL 8.0+ 推荐 DATE_FORMAT(call_start_time, '%Y-%m-%d %H:00:00')；SQLite 只能靠 strftime('%Y-%m-%d %H:00:00', call_start_time)。
注意 call_duration_sec 字段必须是数值型（比如 INT 或 FLOAT），如果存的是 TIME 类型或字符串（如 '00:12:34'），AVG() 会出错或返回意外结果。先用 CAST() 或函数转成秒数再聚合。
过滤无效通话和异常值再算平均
原始数据里常混着测试呼叫、系统自检、超长静音（>30 分钟）或为 0 的脏数据，直接 AVG() 会让结果严重失真。
- 加
WHERE call_duration_sec BETWEEN 1 AND 1800（排除 0 秒和 >30 分钟的记录） - 排除
call_status = 'abandoned'或call_type = 'test'这类非真实服务通话 - 如果业务允许，考虑用
PERCENTILE_CONT(0.5)替代AVG()抗异常值，但注意不是所有数据库都支持
时区处理不当会导致跨小时数据错位
呼叫中心通常有多个地区坐席，call_start_time 如果存的是 UTC，但按本地时区统计每小时均值，就会把北京早 9 点（UTC+8）的通话算进 UTC 时间的凌晨 1 点——结果完全错乱。
解决方案取决于你的分析目标：
- 看“坐席本地运营小时”，用
AT TIME ZONE 'Asia/Shanghai'（PostgreSQL）或CONVERT_TZ()（MySQL）先转时区再截断 - 看“全局统一调度小时”，全部转成 UTC 后再
DATE_TRUNC('hour', ... AT TIME ZONE 'UTC') - 千万别在应用层转时区后传给 SQL——精度丢失、夏令时翻车风险高
结果为空或 NULL 的常见原因
执行完 SQL 却没返回任何行？或者 AVG() 列全是 NULL？大概率是这几个点卡住了：
-
call_start_time是NULL：DATE_TRUNC()对NULL返回NULL，整组被丢弃；加WHERE call_start_time IS NOT NULL - 时间范围太窄：比如查
WHERE call_start_time >= '2024-04-01' AND call_start_time ，实际只覆盖了 1 小时内的前几分钟，可能没数据 call_duration_sec 全被 <code>WHERE过滤掉，导致某小时无有效记录，AVG()返回NULL（不是 0）
上线前务必拿一个已知有数据的小时段（比如今天上午 10–11 点）手动验证，别依赖“逻辑应该没错”。时区、空值、类型转换，三个地方任一出问题，结果就不可信。
