SQL统计各分组内的平均耗时：使用A VG函数计算
A VG()计算前需确保duration为数值类型，否则字符串如‘120ms’会静默转0致结果失真；NULL值默认被忽略，但业务上超时应转极大值处理；URL分组需归一化动态参数；精度问题须显式ROUND或CAST控制。
A VG() 计算分组平均耗时前，必须确保字段是数值类型
有没有遇到过这种情况？明明数据看着没问题，但一用 A VG(duration) 计算，结果要么是0，要么干脆是NULL。问题往往出在源头：duration 字段里存的压根不是纯数字，而是像 ‘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 后用 A VG() 时，NULL 值会被自动忽略
这一点很重要：A VG() 函数在计算时会自动跳过NULL值，这是SQL标准设计，并非程序缺陷。但关键在于，如果业务上把“请求超时未返回”这类失败情况记录为NULL，而你希望这些“失败”能拉低整体的平均耗时（反映真实体验），那么默认行为就与你的业务意图背道而驰了。
该怎么办？核心在于明确NULL在业务中的语义：
- 如果NULL代表“数据缺失”，那忽略它是合理的。但如果它代表“失败/超时”，就应该被计入，并且通常被视为一个极长的耗时。
- 干预计算：使用
A VG(COALESCE(duration_ms, 999999))，将NULL值替换为一个极大的数字（比如999999），强制其参与平均计算，从而显著拉高（恶化）平均值。 - 分离关注点：失败率本身可能比平均耗时更重要。别把两者混在一起算，单独统计更清晰：
COUNT(CASE WHEN duration_ms IS NULL THEN 1 END) * 100.0 / COUNT(*)。
按接口路径分组时，注意 URL 中的动态参数干扰聚合
按接口分组统计是常见需求，但直接对原始URL进行 GROUP BY 很容易掉进坑里。想象一下，/api/user/123 和 /api/user/456 会被当成两个完全不同的接口，导致分组数量爆炸，根本无法看清某个接口模式的整体性能水平。
解决思路是归一化，把动态部分替换成统一标识：
- 数据库层处理：如果数据库支持正则，可以很方便地清洗。例如在MySQL中：
REGEXP_REPLACE(url, ‘/\d+’, ‘/:id’)；PostgreSQL语法类似。 - 应用层预处理：如果数据库版本老旧，更好的做法是在数据入库前，或在ETL过程中，就新增一个
endpoint字段，存放归一化后的路径模式，后续查询直接对这个字段进行分组。 - 性能提醒：尽量避免在
GROUP BY子句中直接使用函数（如GROUP BY SUBSTRING_INDEX(url, ‘?’, 1)），这会导致无法利用索引，在数据量大时查询速度会急剧下降。
A VG() 结果精度不够？小心浮点误差和默认小数位截断
即使数据类型对了，A VG() 给出的结果也可能“骗人”。执行 SELECT A VG(duration_ms) FROM logs GROUP BY endpoint，返回的结果可能显示为整数，但这其实是显示截断造成的假象。MySQL默认大概保留4位小数，PostgreSQL可能更少。底层浮点运算的细微误差，在多次计算累积后，可能会在报表或对比中产生明显偏差。
要获得精确、可靠的结果，必须主动控制精度：
- 显式声明：使用
ROUND(A VG(duration_ms), 2)或CAST(A VG(duration_ms) AS DECIMAL(10,2))来明确指定保留的小数位数。 - 存储类型选择：从一开始就避免使用
FLOAT这类浮点类型存储耗时。优先使用INT（存储毫秒值）或DECIMAL(10,3)（存储带毫秒的秒数）。 - 对比一致性：当进行环比、同比等趋势对比时，确保所有用于计算平均值的字段都使用了相同的精度进行转换，否则小数位数的差异可能会掩盖真实的性能变化。
说到底，技术层面写对一句 A VG() 并不难。真正的挑战在于理解每一行 duration 数据背后的业务状态——它是一次成功的快速响应？还是一次网关超时？亦或是下游服务熔断后返回的兜底值？不把这些业务语义厘清，计算出来的平均值再“准确”，也无法为有效的性能优化提供真正可靠的指导。这才是关键所在。
