17370845950

CAST(float AS DECIMAL) 默认为DECIMAL(18,0)，小数部分向零截断；显式指定精度时四舍五入，但受float二进制误差影响，s不能超15，p≥s+1；避免用float作精确计算源头。

CAST(float AS DECIMAL) 的默认精度陷阱

不显式指定精度时，CAST(float AS DECIMAL) 在 SQL Server 中会退化为 DECIMAL(18,0)，即零小数位——所有小数部分直接截断，不是四舍五入。比如 CAST(3.7 AS DECIMAL) 得到 3，而 CAST(-2.9 AS DECIMAL) 得到 -2（向零截断）。这是最容易被误认为“四舍五入”的行为，实际连舍入都没发生。

显式指定精度时的舍入规则

一旦写成 CAST(float AS DECIMAL(p,s))，SQL

Server 就启用“四舍五入到指定位数”的语义，但注意：它对 float 原始值的二进制近似误差不做补偿。例如：

SELECT CAST(0.1 + 0.2 AS DECIMAL(5,1)) -- 实际计算的是 0.30000000000000004，结果为 0.3
SELECT CAST(0.1 + 0.2 AS DECIMAL(5,17)) -- 报错：精度 17 > 最大允许 15（因 float 只有 ~15 位有效十进制数字）

• s（小数位数）不能超过 15，否则报错 Arithmetic overflow error converting float to data type numeric
• 即使 s=15，若原始 float 表示存在微小偏差（如 0.1 无法精确表示），最终舍入仍可能出人意料
• p（总位数）必须 ≥ s + 1，否则编译失败

float 转 DECIMAL 前先转字符串？不推荐

有人尝试绕过二进制误差：先 CAST(float AS VARCHAR) 再转 DECIMAL。这看似“保留显示值”，实则更危险：

• STR() 或隐式转换受会话 SET NUMERIC_ROUNDABORT 和 SET ARITHABORT 影响，行为不稳定
• CAST(1.2345678901234567e0 AS VARCHAR) 在不同版本中可能截成 '1.234567' 或科学计数法，再转 DECIMAL 丢失精度
• 性能差，且无法解决根本问题：float 本就不该用于需要精确小数的场景

真正安全的替代方案

如果业务逻辑要求精确小数（如金额、比例），唯一可靠做法是避免用 float 作为源头：

• 前端或应用层用字符串或整数传值（如“123.45”或“12345 分”），数据库接收为 DECIMAL
• 已有 float 列需转换？先用 ROUND(float, s, 1) 截断（第三个参数 1 表示截断而非舍入），再 CAST，比直接 CAST 更可控
• 临时调试时可用 CONVERT(DECIMAL(p,s), STR(float, p+2, s)) 强制格式化，但仅限 ad-hoc 查询，不可用于生产逻辑

关键点始终是：float 的舍入差异不是 CAST 函数的问题，而是浮点表示本身不可靠；依赖它做精确小数运算，就像在流沙上盖楼——越调精度，越暴露底层裂缝。