mysql中round()处理浮点精度应优先转decimal再舍入，避免float/double二进制误差；分组排序时宜先放大取整再缩放；注意银行家舍入特性，业务需严格四舍五入时应绕行或应用层处理。
在 MySQL 中用 ROUND() 处理浮点精度，关键不是“会不会用”，而是“在哪用、怎么用才不出错”。直接对 FLOAT 或 DOUBLE 字段调用 ROUND(col, 2)，结果可能和你心里想的不一样——不是函数错了，是浮点数底层存不准。
优先把浮点列转成 DECIMAL 再 ROUND
这是最稳妥的做法。MySQL 的 DECIMAL 类型按十进制精确存储，不会出现 0.1 + 0.2 = 0.30000000000000004 这类问题。
- 写法示例：
ROUND(CAST(price AS DECIMAL(10,4)), 2) - 含义：先把
price（哪怕它是DOUBLE）转成最多 10 位、小数 4 位的定点数，再四舍五入到 2 位 - 比
ROUND(price, 2)更可靠，尤其当原始值接近舍入边界（如 1.235）时
分组或排序时别直接 ROUND 浮点列
在 GROUP BY ROUND(price, 2) 或 ORDER BY ROUND(price, 1) 场景下，FLOAT/DOUBLE 的二进制误差会被放大，导致本该归为一组的数值被拆开。
- 错误写法：
SELECT ROUND(price, 1) g, COUNT(*) FROM sales GROUP BY g - 推荐替代：
SELECT ROUND(price * 10) / 10.0 g, COUNT(*) FROM sales GROUP BY g（先放大、取整、再缩回，减少中间误差） - 更彻底的解法：建表时就把
price定义为DECIMAL(10,2)，从源头杜绝问题
注意 ROUND 默认是银行家舍入，不是传统四舍五入
比如 ROUND(2.5, 0) 返回 2，ROUND(3.5, 0) 返回 4——它向偶数靠拢，目的是降低统计偏差。财务系统常用这个特性，但业务上若明确要求“严格四舍五入”，得绕一下：
- 正数场景：
FLOOR(x + 0.5) - 通用场景（含负数）：
ROUND(x + SIGN(x) * 0.5 - 0.5) - 或者干脆在应用层做舍入，数据库只负责存原始高精度值
插入前处理比查询时处理更可控
与其每次查都 ROUND()，不如在写入时就规范好精度：
- 插入语句中主动处理：
INSERT INTO orders (final_price) VALUES (ROUND(9.99 * 0.8, 2)) - 字段定义留余量：
DECIMAL(12,4)存中间计算值，查询时再ROUND(..., 2) - 用
SHOW COLUMNS FROM table_name确认字段真实类型，别依赖印象或文档假设
