group by浮点数是建模错误，因ieee 754无法精确表示十进制小数，导致本应同组的数据被拆分；正确做法是用decimal存储或转整型单位（如floor(price*100)）分组。
GROUP BY 浮点数本身就不该发生——这不是精度问题，是建模错误。 真正要解决的，是“为什么你正在用 FLOAT/DOUBLE 字段做分组依据”。
为什么不能直接 GROUP BY price（FLOAT类型）
浮点数在 IEEE 754 下无法精确表示十进制小数，比如 19.99 在内存中可能是 19.989999999999998 或 19.990000000000002。哪怕原始数据看起来一样，GROUP BY 比较的是二进制值，不是字符串或四舍五入后的视觉值。结果就是：本该同一组的两行，被拆成两个分组。
常见错误现象：
- 同一价格显示为相同值，但
COUNT(*)却分散在多行 - 用
ROUND(price, 2)分组后，某些价格段统计数异常偏高（如20.00组里混进了19.995和20.004） - MySQL 报错
Invalid column name（SQL Server）或聚合结果不一致（PostgreSQL/MySQL）
正确做法：从源头避免浮点参与分组
核心原则：分组键必须是确定性、可比较、无误差的值。优先级如下：
- 建表时就用
DECIMAL(10,2)或NUMERIC(10,2)存金额类字段，而不是FLOAT或DOUBLE - 若已有浮点列且无法改表，聚合前转整型单位：
FLOOR(price * 100)（单位：分），再按这个整数分组 - 需要区间分组（如“0–99.99”、“100–199.99”），用
CASE WHEN price BETWEEN 0 AND 99.99 THEN '0-99.99'，别依赖数值四舍五入 - 临时应急（仅限调试）：加微小偏移压制误差扰动，如
GROUP BY ROUND(price + 1e-12, 2)，但业务逻辑需确认是否接受这种舍入合并
ROUND(price, 2) 在 GROUP BY 中到底能不能用
能语法通过，但语义危险——它不是“按两位小数分组”，而是“把所有四舍五入后相等的原始值强行归并”。例如：
19.995 → ROUND → 20.00<br>20.004 → ROUND → 20.00<br>但 19.995 和 20.004 的业务含义可能完全不同（一个是满减后价格，一个是含税价）
所以：
- MySQL 支持
GROUP BY ROUND(price, 2)，但结果不可靠 - SQL Server 要求写成
SELECT ROUND(price, 2) AS p, COUNT(*) FROM t GROUP BY p，否则报Invalid column name - PostgreSQL 允许，但同样面临语义漂移风险
- 真正稳定替代：用
TRUNCATE(price, 2)（MySQL）或FLOOR(price * 100) / 100.0（通用），它们是截断而非四舍五入，边界更可控
SUM() 和 ROUND() 配合输出时的坑
ROUND(SUM(price), 2) 只控制最终显示位数，不修复中间计算的浮点误差。比如 SUM 算出来是 99.99999999999999，ROUND(..., 2) 得到 100.00，看起来对了，但如果你还要拿这个结果做后续计算（比如除以数量），误差还在。
更稳妥的做法：
- 先转整型单位累加：
SUM(ROUND(price * 100)) / 100.0（注意：ROUND 要在 SUM 前） - 或者全程用
DECIMAL类型字段，让数据库底层保证精度 - 不要在 WHERE 或 HAVING 中用
ROUND(price, 2) = 19.99做条件——改用ABS(price - 19.99)
最常被忽略的一点：浮点偏差不是“算得不准”，而是“不该让它参与分组或等值判断”。只要分组键本身不稳定，后面所有聚合、JOIN、子查询都会继承这个不确定性。处理的关键永远在输入端，不在 ROUND 或 HAVING 上打补丁。
