avg()计算前需确保duration为数值类型，否则字符串如'120ms'会静默转0致结果失真；null值默认被忽略，但业务上超时应转极大值处理；url分组需归一化动态参数；精度问题须显式round或cast控制。
AVG() 计算分组平均耗时前，必须确保字段是数值类型
直接对 duration 字段用 AVG() 却得到 0 或 NULL？大概率是字段存的是字符串，比如 '120ms'、'3.5s'，或者空字符串、'-' 这类非数字占位符。MySQL 和 PostgreSQL 都会静默转成 0 再参与计算，结果失真但不报错。
实操建议：
- 先用
SELECT duration, LENGTH(TRIM(duration)), duration+0 FROM logs LIMIT 5看字段真实内容和隐式转换结果 - 清理数据：用
CAST(REPLACE(REPLACE(duration, 'ms', ''), 's', '') AS DECIMAL(10,3))提纯数字（注意单位统一） - 更稳妥的做法是在写入时就校验并转为毫秒整数存进
duration_ms字段，避免每次查都做字符串处理
GROUP BY 后用 AVG() 时，NULL 值会被自动忽略
这是 SQL 标准行为，不是 bug。但如果业务上“超时未返回”被记为 NULL，而你希望它拉低平均值，就得主动干预——AVG() 不吃这一套。
实操建议：
- 明确 NULL 的语义：是“无数据”还是“失败/超时”？前者该剔除，后者建议转成一个极大值（如
999999）再参与计算 - 用
AVG(COALESCE(duration_ms, 999999))强制把 NULL 当超长耗时处理 - 如果想单独统计失败率，别塞进 AVG，改用
COUNT(CASE WHEN duration_ms IS NULL THEN 1 END) * 100.0 / COUNT(*)
按接口路径分组时，注意 URL 中的动态参数干扰聚合
像 /api/user/123 和 /api/user/456 如果直接 GROUP BY url，会拆成上百个组，根本看不出接口整体水位。
实操建议：
- 预处理路径：用正则或字符串函数归一化，例如 MySQL 用
REGEXP_REPLACE(url, '/\d+', '/:id')，PostgreSQL 用REGEXP_REPLACE(url, '/[0-9]+', '/:id') - 如果数据库版本太低不支持正则，可在应用层或 ETL 阶段加一列
endpoint存归一化后的路径，查询只 GROUP BY 这列 - 避免在 SELECT 中用函数包裹分组字段（如
GROUP BY SUBSTRING_INDEX(url, '?', 1)），会导致索引失效，大数据量下变慢
AVG() 结果精度不够？小心浮点误差和默认小数位截断
执行 SELECT AVG(duration_ms) FROM logs GROUP BY endpoint 得到一堆整数，其实不是真整数，而是显示被截断了。MySQL 默认保留 4 位小数，PostgreSQL 可能更少，但底层仍是浮点运算，累积误差在报表里会明显。
实操建议：
- 显式控制精度：
ROUND(AVG(duration_ms), 2)或CAST(AVG(duration_ms) AS DECIMAL(10,2)) - 别用
FLOAT类型存耗时，一律用INT（毫秒）或DECIMAL(10,3)（秒级带毫秒） - 如果要做趋势对比（比如环比），记得所有 AVG 结果统一用相同精度 CAST，否则小数位差异可能掩盖真实变化
最麻烦的从来不是写对 AVG()，而是搞清每一行 duration 背后代表什么业务状态——是成功响应？是网关超时？还是下游服务熔断返回的兜底值？这些语义不厘清，再准的平均数也没法指导优化。
