ROUND函数在分组统计中易引发精度偏差、显示异常和索引失效：AVG后直接ROUND放大浮点误差，银行家舍入可能不合规，类型继承导致尾随零，百分比加总失衡，WHERE中使用会绕过索引。
ROUND 是最直接的手段，但分组后直接套用容易出偏差、显示异常或掩盖精度问题。别指望它“一写就准”。
GROUP BY 后对 AVG() 结果四舍五入，必须先 SUM 再 ROUND
常见错误是写成 ROUND(AVG(score), 2) —— 看似合理，实则危险：
• 如果 score 是 FLOAT 或低精度类型，AVG() 自身已带浮点误差，再 ROUND 可能放大偏差
• 更严重的是：某些数据库（如 SQL Server）对 .5 采用银行家舍入（ROUND(2.5, 0) → 2），财务场景可能不合规
• 正确做法是显式控制精度链：ROUND(CAST(SUM(score) AS DECIMAL(18,6)) / COUNT(*), 2)
为什么 ROUND(avg_col, 2) 返回 85.750 而不是 85.75
这不是 bug，是类型继承行为：
• AVG() 在多数数据库中默认返回 DECIMAL(p,s) 或 FLOAT，小数位宽由输入字段决定
• ROUND(85.75, 2) 若输入是 DECIMAL(10,3)，结果仍是三位小数（85.750）
• 想彻底去掉尾随零，必须强制转精度：CAST(ROUND(AVG(score), 2) AS DECIMAL(10,2))
• MySQL 可用 CONVERT(DECIMAL(10,2), ROUND(AVG(score), 2))，PostgreSQL 推荐 ROUND(AVG(score), 2)::DECIMAL(10,2)
分组统计后百分比加总≠100%，ROUND 不是罪魁，但会暴露它
比如三组占比原始值为 33.333... ×3，ROUND(x, 2) 后变成 33.33 + 33.33 + 33.33 = 99.99：
• 这是四舍五入的数学必然，不是 SQL 实现缺陷
• 若业务强依赖“加总必须 100%”，不能靠 ROUND 修复，得用应用层补偿逻辑（如把最大余数项 +0.01）
• 数据库层可临时绕过：用 FLOOR(value * 100 + 0.5) / 100.0 强制进位（但注意浮点误差边界）
• 别写 ROUND(value + 0.005, 2) —— 1.235 + 0.005 在二进制下可能 ≠ 1.240
WHERE 或 ORDER BY 里用 ROUND(group_col, 0) = 100？小心索引失效
这是最容易被忽略的性能陷阱：
• ROUND(amount, 0) = 100 会让数据库无法使用 amount 字段上的普通索引
• 因为函数改变了原始值，优化器没法做范围估算
• 高频过滤应改用区间：amount >= 99.5 AND amount <br>• 真要函数过滤，SQL Server 和 PostgreSQL 支持函数索引，但需显式创建：<code>CREATE INDEX idx_rounded_amount ON t (ROUND(amount, 0))
分组后的数值处理，核心矛盾从来不在“怎么写 ROUND”，而在于你是否清楚自己要的是数学近似、显示格式，还是业务合规性——三者目标冲突时，ROUND 只能负责第一项。
