SQL分配sum()结果非整数：AWS Athena保留循环小数需求

我之前也踩过类似的浮点精度坑，针对你这种把1个单位分配到多行后求和出现非整数的情况，给你几个实用的解决方案：

方案1：从分配逻辑上消除误差（最彻底） #

核心思路是让最后一个需要分配的项承担所有精度误差，确保总和严格等于原单位值。比如在你的访问分配场景中，先计算大部分项的分配值，最后一个中间项用0.2 - 其他中间项的和来得到，这样中间部分总和固定为0.2，加上首尾的0.4+0.4，最终总和必然精准为1。

用窗口函数实现的具体SQL示例：

WITH initial_alloc AS (
    SELECT
        your_group_key, -- 替换为你的分组字段（比如用户ID）
        visit_seq_number,
        count_of_visits,
        min_visit_seq_number,
        max_visit_seq_number,
        -- 先计算初始分配值（除了需要补差值的中间项）
        CASE
            WHEN count_of_visits = 1 THEN 1
            WHEN count_of_visits = 2 THEN 0.5
            WHEN visit_seq_number = min_visit_seq_number THEN 0.4
            WHEN visit_seq_number = max_visit_seq_number THEN 0.4
            ELSE 0.2 / (count_of_visits - 2)
        END AS temp_alloc
    FROM your_table
)
SELECT
    your_group_key,
    visit_seq_number,
    CASE
        -- 针对最后一个中间项，用0.2减去其他中间项的和来补全
        WHEN visit_seq_number NOT IN (min_visit_seq_number, max_visit_seq_number) 
             AND visit_seq_number = (
                 SELECT MAX(visit_seq_number) 
                 FROM initial_alloc 
                 WHERE your_group_key = ia.your_group_key 
                   AND visit_seq_number NOT IN (min_visit_seq_number, max_visit_seq_number)
             )
        THEN 0.2 - SUM(temp_alloc) OVER (
            PARTITION BY your_group_key 
            WHERE visit_seq_number NOT IN (min_visit_seq_number, max_visit_seq_number) 
              AND visit_seq_number != ia.visit_seq_number
        )
        ELSE temp_alloc
    END AS u_shp_alloc_leads
FROM initial_alloc ia

方案2：使用DECIMAL类型替代DOUBLE #

Athena中的DOUBLE是二进制浮点类型，无法精确表示像0.2/27这样的十进制循环小数，存储时会产生微小截断误差。改用高精度DECIMAL类型可以大幅降低这类问题的影响：

• 建表时将u_shp_alloc_leads字段定义为DECIMAL(18, 12)（根据需求调整小数位数）
• 计算分配值时强制转为DECIMAL类型：

CAST(
    CASE
        WHEN count_of_visits = 1 THEN 1
        WHEN count_of_visits = 2 THEN 0.5
        WHEN visit_seq_number = min_visit_seq_number THEN 0.4
        WHEN visit_seq_number = max_visit_seq_number THEN 0.4
        ELSE 0.2 / (count_of_visits - 2)
    END AS DECIMAL(18,12)
) AS u_shp_alloc_leads

注：这个方案只能减少误差，极端场景下仍可能有微小偏差，建议和方案1结合使用。

方案3：求和时做精度修正（快速临时方案） #

如果不想修改分配逻辑，可以在求和环节对结果做精度截断或四舍五入，快速解决显示问题：

SELECT
    your_group_key,
    ROUND(SUM(u_shp_alloc_leads), 9) AS total_alloc -- 保留9位小数足够覆盖你的场景
FROM your_table
GROUP BY your_group_key

或者用CAST强制转为DECIMAL来约束精度：

SELECT
    your_group_key,
    CAST(SUM(u_shp_alloc_leads) AS DECIMAL(18,9)) AS total_alloc
FROM your_table
GROUP BY your_group_key

内容的提问来源于stack exchange，提问作者drazen90909