MySQL的ROUND()默认采用“四舍六入五成双”规则，非传统四舍五入；需显式指定小数位数、避免浮点误差、慎用DECIMAL存储精度限制，并区分TRUNCATE的截断特性。
ROUND函数怎么用才不丢精度
MySQL的ROUND()默认按“四舍六入五成双”（银行家舍入）规则处理，不是简单四舍五入。比如ROUND(2.5)得2，ROUND(3.5)得4——这和多数人直觉不符，尤其做财务计算时容易出错。
实操建议：
- 明确指定小数位数：用
ROUND(x, d)，其中d必须是整数；d为负数时向左舍入（如ROUND(1234.56, -2)→ 1200） - 避免依赖默认行为：不写第二参数等价于
ROUND(x, 0)，仍走银行家舍入 - 如果真要“传统四舍五入”，改用
CAST(ROUND(x + 0.5 * SIGN(x), d) AS DECIMAL(...))这类手动偏移法（但要注意x为负数时SIGN(x)返回-1）
DECIMAL字段里ROUND没效果？检查数据类型定义
常见错误：建表时写price DECIMAL(10,2)，插入9.995后查出来还是9.99，以为ROUND(price, 2)没起作用——其实是插入时就被截断了，根本没进到ROUND环节。
原因在于：DECIMAL(M,D)的D是存储精度上限，超出部分直接截断（非四舍五入），且该行为不可逆。
实操建议：
- 插入前就用
ROUND()处理原始值，再存入DECIMAL字段 - 若需保留中间精度，字段定义留足余量，比如预期存2位小数，可设
DECIMAL(10,4)，计算完再ROUND(..., 2) - 用
SHOW COLUMNS FROM table_name确认字段实际定义，别只看业务逻辑假设
ROUND在GROUP BY或ORDER BY里导致结果不稳定
当ROUND()用于分组或排序字段，尤其是对浮点列（如DOUBLE）操作时，可能因底层二进制表示误差，让本该相等的值被分到不同组或排错序。
例如：SELECT ROUND(price, 1) g, COUNT(*) FROM sales GROUP BY g，若price是DOUBLE类型，1.15可能存成1.1499999999999999，ROUND()后变成1.1而非1.2。
实操建议：
- 优先把浮点列转成
DECIMAL再ROUND，如ROUND(CAST(price AS DECIMAL(10,3)), 1) - 分组/排序场景下，避免直接
ROUND(double_col, d)，改用ROUND(double_col * POWER(10,d)) / POWER(10,d)先放大再取整再缩回（减少浮点误差累积） - 测试时用
SELECT price, BIN(price), ROUND(price,1) FROM ... LIMIT 5观察原始二进制值，确认是不是浮点表示问题
ROUND和TRUNCATE的区别不能只看文档
TRUNCATE(x, d)是直接截断，不四舍五入；ROUND(x, d)是按规则舍入。但关键差异在边界行为和类型处理上。
比如TRUNCATE(1.999, 2) → 1.99，而ROUND(1.999, 2) → 2.00；更隐蔽的是：TRUNCATE对DECIMAL和DOUBLE都严格按位截，ROUND在DOUBLE上可能因精度丢失表现异常。
实操建议：
- 需要确定性截断（比如取前N位不进位），无条件选
TRUNCATE() - 涉及金额、计费等场景，一律用
DECIMAL列 +ROUND()，别混用DOUBLE -
ROUND()返回类型继承输入类型，ROUND(1.5, 0)返回DECIMAL，但ROUND(1.5E0, 0)返回DOUBLE——后续计算可能隐式转类型，引发精度漂移
最麻烦的不是函数不会用，而是你不知道它在哪个环节悄悄变了类型、丢了精度。盯着DESCRIBE结果和SELECT ... + 0看实际数值表现，比背文档管用。
