浮点数GROUP BY分组异常的根本原因是二进制存储精度导致值不等价；ROUND()直接用于GROUP BY会因中间精度丢失而失效；应优先采用整型归一化（如FLOOR(price*100)）或业务层预存price_cents字段。
浮点数字段直接用于 GROUP BY 会导致分组异常，根本原因不是数据“看起来一样”，而是二进制存储精度导致的值不等价——数据库眼里它们是不同值，自然不会归为一组。
为什么 ROUND(price, 2) 放进 GROUP BY 会失效
把 ROUND() 直接写进 GROUP BY 子句（如 GROUP BY ROUND(price, 2)）看似能合并相近价格，实际常让本该同组的记录被拆开。这是因为：
- 浮点计算发生在 GROUP BY 执行阶段，但不同行的舍入可能因中间精度丢失而产生微小差异（比如
19.995和19.994999999999998都被显示为19.99，但舍入结果可能是19.99和20.00） -
ROUND()是逐行计算后再分组，不是先对原始值做归一化再分组，无法消除底层二进制表示的歧义 - MySQL 对浮点数的舍入实现与 IEEE 754 标准存在细微偏差，跨版本行为可能不一致
更稳妥的替代方案：用整型或字符串归一化
避免在分组逻辑中依赖浮点运算，优先将数值映射为确定性更强的类型：
- 转为整型分组：
GROUP BY FLOOR(price * 100)（把元转成分，19.99→1999） - 转为标准化字符串：
GROUP BY TRIM(TRAILING '0' FROM TRIM(TRAILING '.' FROM CAST(ROUND(price, 2) AS CHAR)))，但性能差，仅作调试参考 - 业务层预处理：在 INSERT/UPDATE 时就存
price_cents INT字段，分组直接用它，彻底规避浮点问题
检查是否真由浮点引起：用 HEX() 看底层字节
当怀疑两行“相同”的浮点值实际不同，可用 HEX() 暴露真实二进制表示：
SELECT price, HEX(price) FROM orders WHERE ABS(price - 19.99) < 0.01 LIMIT 5;
如果返回的 HEX() 值不一致，说明它们在存储层面就是不同值——这时强行 GROUP BY 或 ROUND() 都只是掩盖问题，而非解决。
真正难处理的不是“怎么让它们分到一组”，而是确认业务上是否允许这种精度合并；一旦接受归并，就必须在数据写入源头或查询前统一归一化逻辑，而不是指望 GROUP BY 帮你猜意图。
