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 函数的问题，而是浮点表示本身不可靠；依赖它做精确小数运算，就像在流沙上盖楼——越调精度，越暴露底层裂缝。
