根本原因是FLOAT/DOUBLE无法精确表示十进制小数，导致窗口计算中误差累积；必须在进入窗口函数前用CAST转为DECIMAL，如SUM(CAST(price AS DECIMAL(15,2))) OVER (...)，否则ROUND等后续操作无法修复已污染的计算链路。

窗口函数里用FLOAT字段直接计算，结果不准怎么办

根本原因不是窗口函数本身有问题，而是底层字段类型是 FLOAT 或 DOUBLE ——它们在二进制中无法精确表示 0.1、0.01 这类十进制小数，累加、排序、分组时误差会放大。比如 SUM(price) OVER (PARTITION BY category) 返回 99.99999999999999 而非 100.00，后续 ROUND() 也救不回来。

解决路径只有一条：在进入窗口计算前，把浮点列转成定点数。不能依赖窗口函数内部做转换，必须显式前置处理。

• 错误写法：SUM(price) OVER (...) → price 是 FLOAT，SUM 结果仍是近似值
• 正确写法：SUM(CAST(price AS DECIMAL(15,2))) OVER (...)，先转再算
• 若表结构已定且无法改字段类型，可在查询开头用 WITH 子句统一转换，避免重复写 CAST

DECIMAL精度参数怎么设才不踩坑

DECIMAL(p,s) 的两个参数直接影响计算是否溢出或截断。p 是总位数（整数+小数），s 是小数位数。常见误设是 s 固定为 2，但业务实际可能需要 4 位（如汇率）、6 位（如科学测量）。

• 金融类场景：用 DECIMAL(18,2) 足够，但注意 SUM 后整数位可能超限，建议留足余量，如 DECIMAL(20,2)
• 多层计算（如先乘后除）：中间结果小数位会叠加，DECIMAL(10,2) * DECIMAL(10,2) 理论上需 DECIMAL(20,4) 才不丢精度
• MySQL 严格模式下，超出 p 会报错；非严格模式则静默截断，务必确认数据库配置

ORDER BY + ROW_NUMBER() 遇到 FLOAT 排序错乱

当用 FLOAT 字段做窗口排序依据（如 ORDER BY score），微小误差会导致相同逻辑值被拆到不同位置，ROW_NUMBER() 分配序号错位，RANK() 并列判断失效。

• 典型现象：score = 95.0 实际存为 94.99999999999999，和真正的 95.0 被当成不同值
• 必须转换后再排序：ORDER BY CAST(score AS DECIMAL(10,3))
• 如果原始数据误差已存在（如从 CSV 导入未清洗），仅靠 CAST 不够，需配合 ROUND(score, 3) 先归一化
• 注意：ORDER BY 中的表达式无法走索引，高频查询应提前在应用层或 ETL 阶段固化为 DECIMAL 列并建索引

为什么不能只在最后 SELECT 里 ROUND

很多人试图在最终输出层用 ROUND(SUM(price) OVER (...), 2) 解决问题，这只能掩盖显示问题，无法修正计算过程中的精度污染。

• 窗口函数内部聚合仍基于 FLOAT 值，比较、累计、分组逻辑全受影响
• ROUND() 返回类型由输入决定：输入是 FLOAT，输出仍是 FLOAT，误差没消失，只是四舍五入后看起来“对”了
• PostgreSQL 中 ROUND(float_col, 2) 返回 double precision，不是 NUMERIC；MySQL 8.0+ 才支持 ROUND(...) 返回定点数，旧版仍返回浮点
• 真正安全的做法：所有参与窗口计算的数值，从源头开始就是 DECIMAL 类型

关键点在于：浮点误差一旦进入计算链路，就不可逆。DECIMAL 转换不是锦上添花，而是必须卡在最上游——在第一个聚合、排序、比较发生之前完成。