AVG()在GROUP BY中需注意三类问题：一是自动忽略NULL且要求数值类型，字符串需显式转换；二是耗时单位不统一须先转为毫秒再聚合；三是GROUP BY维度缺失或WHERE/HAVING误用会导致结果失真。
AVG() 函数在 GROUP BY 中直接用就行，但 NULL 和类型不匹配会悄悄吃掉结果
SQL 里算分组平均耗时，AVG() 配 GROUP BY 是最直觉的写法，但实际一跑常发现结果比预期少、数值偏小，甚至报错。核心问题不在语法，而在数据本身——AVG() 会自动跳过 NULL 值，且要求字段是数值型。如果耗时字段是字符串（比如 '120ms'）、或存了 'timeout' 这类标记，AVG() 不会报错，而是把整行当 NULL 处理。
- 查之前先确认字段类型：
SELECT data_type FROM information_schema.columns WHERE table_name = 'logs' AND column_name = 'duration_ms'; - 如果字段是
TEXT或VARCHAR，必须显式转换：AVG(CAST(duration_str AS INTEGER))（PostgreSQL/MySQL 8.0+），或用SAFE_CAST（BigQuery） - 想保留非数字行做标记？别依赖
AVG()自动过滤，先用CASE WHEN清洗：AVG(CASE WHEN duration_str ~ '^\d+$' THEN duration_str::INT END)
耗时单位不统一导致 AVG 结果完全失真
日志里常见 '500ms'、'2.3s'、'1m20s' 混存，直接 AVG() 就等于拿苹果和橙子算平均重量。数据库不会自动帮你换算，它只会尝试转成数字——'2.3s' 可能转成 2（截断），'1m20s' 直接变 NULL。
- 统一转成毫秒再聚合是最稳的做法，例如 PostgreSQL：
AVG(EXTRACT(EPOCH FROM duration_interval) * 1000)（前提是已转成INTERVAL） - 没转好类型？用正则提取数字再判断单位：
AVG(REGEXP_REPLACE(duration_raw, '(\d+)(ms|s|m)', '\1')::INT * CASE WHEN duration_raw ~ 'ms$' THEN 1 WHEN duration_raw ~ 's$' THEN 1000 ELSE 60000 END) - 别在应用层补单位换算——聚合发生在数据库，单位不一致的原始值一旦进
AVG()，误差就不可逆
GROUP BY 字段漏了关键维度，平均值看起来“合理”实则无意义
比如按 endpoint 分组算平均耗时，结果看着正常，但实际 /api/v1/users 有缓存命中和未命中两种路径，耗时差 10 倍。如果没把 cache_hit（布尔值）或 status_code 加进 GROUP BY，平均值只是把快慢请求强行揉在一起，掩盖了真实瓶颈。
- 先看业务语义：耗时差异是否由某个字段驱动？比如错误请求通常更慢，那就加
status_code；移动端请求普遍比桌面端慢，那就加user_agent_category - 临时排查时，用
GROUPING SETS一次看多维组合：GROUP BY GROUPING SETS ((endpoint), (endpoint, status_code)) - 注意
GROUP BY后所有非聚合字段都必须出现，否则 MySQL 5.7+ 严格模式会报错：SELECT endpoint, AVG(duration_ms), COUNT(*) FROM logs GROUP BY endpoint;—— 这个没问题；但加个created_date就得一起GROUP BY，不能只选不聚
WHERE 条件写在 GROUP BY 之后？逻辑错位会让 AVG 完全偏离目标
新手容易把过滤条件放错位置：想查「成功请求的平均耗时」，却写成 GROUP BY endpoint HAVING status_code = 200。这是错的——HAVING 是对分组结果过滤，不是对原始行过滤。HAVING 里用 status_code（单个值）等价于检查该分组是否包含 200，而不是只拿 200 的行去算平均。
- 行级过滤一律用
WHERE：SELECT endpoint, AVG(duration_ms) FROM logs WHERE status_code = 200 GROUP BY endpoint; -
HAVING只用于聚合后筛选，比如「只看平均耗时超 500ms 的接口」：HAVING AVG(duration_ms) > 500 - 如果要同时满足「只算 200 请求」+「只显示平均 > 500ms 的分组」，
WHERE和HAVING得一起用，顺序不能颠倒
真正麻烦的是嵌套时间窗口——比如「每小时各接口平均耗时」，这时 GROUP BY 要配合 date_trunc('hour', request_time) 或 DATE_FORMAT(request_time, '%Y-%m-%d %H:00:00')，而这类函数在不同数据库写法差异大，稍不注意就会让分组边界错位，平均值跨小时被拉平。这种地方没法靠背语法，得对着样本数据手动验证分组结果是否符合时间切片预期。
