SQL如何处理分组统计中的浮点数精度_ROUND与聚合函数结合
先说一个核心判断：ROUND()函数的作用，仅仅是控制最终显示的精度，它并不改变内部计算的精度。这个函数应该用在输出层，如果滥用在内层聚合或GROUP BY中，很容易引入意想不到的误差或逻辑错误。
ROUND() 套在聚合函数外面才真正控制显示精度
这里有个常见的误解。很多人以为ROUND(SUM(price), 2)是在对求和过程进行四舍五入，其实完全不是这么回事。真实的情况是：SUM()函数先计算出完整的浮点数结果，然后ROUND()才对这个最终结果做一次截断处理。数据库内部在后续计算中（比如再除以数量），依然使用的是原始精度。所以，别指望它能“修复”中间累积的误差。
- 正确姿势是：把所有精度控制都放在最终输出层。举个例子，
SELECT ROUND(A VG(score), 3) FROM exam，这就很清晰。 - 如果需要用于比较或
JOIN操作，千万别依赖ROUND()后的值去做等值判断。浮点数的本质没变，只是显示变短了而已。 - 值得注意的是，PostgreSQL和MySQL对
ROUND()的舍入规则存在细微差异。比如遇到0.5时，MySQL默认采用“四舍五入”（round half away from zero），而PostgreSQL默认采用“银&行家舍入法”（round half to even）。跨数据库迁移时，这一点必须留意。
GROUP BY + 聚合 + ROUND() 的典型错误写法
来看一个典型的翻车现场：SELECT ROUND(price, 2), COUNT(*) FROM sales GROUP BY ROUND(price, 2)。这写法看起来是想“按保留两位小数的价格进行分组”，对吧？但实际效果是，它会把19.995和20.004都四舍五入成20.00，从而强行合并了原本不该属于同一组的数据。
- 如果真想按价格区间分组，应该使用
FLOOR(price * 100) / 100或MySQL中的TRUNCATE(price, 2)这类截断函数，而不是四舍五入函数。 - 如果业务场景确实允许这种舍入合并逻辑，那当然可以用
ROUND()分组。但在此之前，必须确认清楚，否则统计口径从一开始就歪了。 - 另外，SQL Server不支持直接在
GROUP BY子句里写ROUND()表达式（除非先定义列别名，然后在GROUP BY中引用这个别名），否则很容易报Invalid column name错误。
聚合前先 ROUND()？多数情况没必要且有害
写成A VG(ROUND(price, 2))，感觉上似乎“更干净”？其实不然，这反而会引入额外的偏差。它的过程是：每个原始值先被单独四舍五入，然后再求平均。这相当于把每一步的舍入误差都放大了。尤其是当price本身是高精度的DECIMAL类型，或者带有多位小数的FLOAT类型时，这种误差更不可忽视。
- 除非业务有明确要求，比如“每一笔交易都必须先四舍五入到账单金额，然后再计算平均值”，否则，一律避免在聚合函数的内层嵌套
ROUND()。 - 对于
DECIMAL类型的字段（例如DECIMAL(10,4)），进行SUM()或A VG()运算时，数据库会自动保持其精度。这时候，既不需要、也不应该提前做ROUND()处理。 - 话说回来，用
FLOAT类型来存储金额本身就是一个隐患，ROUND只是打补丁。治本的方法，是换成DECIMAL类型。
不同数据库对 ROUND() 和聚合的兼容细节
同一个SQL语句，在MySQL、PostgreSQL、SQL Server上跑，行为可能不一致。特别是在处理NULL值、溢出或边界值时，差异会更明显。
- 舍入规则：MySQL的
ROUND(2.5, 0)返回3，而PostgreSQL默认返回2（即银&行家舍入法）。 - 负精度处理：SQL Server中
ROUND(123.456, -1)会得到120，但某些旧版本对负精度的处理可能存在bug，建议进行显式测试。 - SQLite的特别情况：SQLite没有原生的
ROUND()函数，通常需要用CAST(ROUND(x*100)/100 AS REAL)这种方式曲线救国。但要注意，REAL是8字节浮点数，依然存在精度风险。
事情其实很清晰：ROUND不是精度问题的保险丝，它只是最后那一下“决定如何展示”。真要追求稳定和精确，功夫得下在前面——从选择合适的数据类型开始，理清聚合逻辑，并摸透目标数据库的具体行为。这才是关键所在。
