Redshift查询字符串/时间戳列触发NUMERIC(38,37)溢出错误如何修复

这个报错和SELECT列表里的字符串、时间戳字段没有直接关系，两个最高频触发场景：

• 多表按billId直接LEFT JOIN产生严重join扇出（笛卡尔积爆炸）。Redshift执行分布式哈希JOIN时，内部做基数统计、分桶计数、倾斜比例计算会用到NUMERIC(38,37)类型的高精度计算变量，中间结果规模过大时会直接触发该类型的计算溢出。因为问题出在执行引擎的内部计算逻辑，和查询显式返回的字段无关，你之前仅对SELECT列表的字段做类型转换，完全没有触发出问题的逻辑层，自然无法修复。
• 建临时表时关联键被隐式推断为NUMERIC(38,37)类型。比如用CTAS创建临时表时，如果源端billId字段是高精度数值类型，没有做显式类型转换，即使你存的是类数字字符串，也可能被自动设为该高精度数值类型，值超出存储范围时就会抛错。

按顺序执行以下校验即可快速定位根因：

1. 校验每个表关联键的重复度，确认扇出规模。分别对四个表执行如下SQL（执行时替换对应表名），查看同一个billId下的最大记录数：

SELECT billId, COUNT(*) AS cnt 
FROM TAB1 
GROUP BY billId 
ORDER BY cnt DESC 
LIMIT 10;

如果四个表同一个billId的记录数乘积超过1亿级别，基本可以确定是join扇出导致的内部计算溢出。
2. 校验临时表的实际字段类型，确认关联键没有被隐式设为高精度数值类型：

SELECT "column", type 
FROM PG_TABLE_DEF 
WHERE tablename IN ('tab1','tab2','tab3','tab4')
AND "column" = 'billid';

• 针对join扇出场景：禁止直接把多个同关联键的表做全量LEFT JOIN，先对每个关联表做去重或预聚合，收敛到billId粒度后再做关联。如果每个billId在子表中确实有多条记录，按业务规则取唯一匹配的记录即可，示例写法如下：

-- 对子表按billId去重，示例取每个billId下最新结束时间的1条记录
WITH TAB2_dedup AS (
  SELECT * FROM (
    SELECT *,
      ROW_NUMBER() OVER(PARTITION BY billId ORDER BY end_time DESC) AS rn
    FROM TAB2
  ) WHERE rn = 1
),
TAB3_dedup AS (
  SELECT * FROM (
    SELECT *,
      ROW_NUMBER() OVER(PARTITION BY billId ORDER BY end_time DESC) AS rn
    FROM TAB3
  ) WHERE rn = 1
),
TAB4_dedup AS (
  SELECT * FROM (
    SELECT *,
      ROW_NUMBER() OVER(PARTITION BY billId ORDER BY end_time DESC) AS rn
    FROM TAB4
  ) WHERE rn = 1
)
SELECT
 TAB1.accountId 
 ,TAB1.account_type
 ,TAB2_dedup.billId
 ,TAB1.type AS TAB1_TYPE
 ,TAB1.START_TIME  
 ,TAB1.END_TIME
 ,TAB2_dedup.start_time AS TAB2_START_TIME  
 ,TAB2_dedup.end_time AS TAB2_END_TIME
 ,TAB3_dedup.producer AS TAB3_PRODUCER
 ,TAB3_dedup.start_time AS TAB3_START_TIME  
 ,TAB3_dedup.end_time AS TAB3_END_TIME
 ,TAB4_dedup.type AS TAB4_TYPE
 ,TAB4_dedup.start_time AS TAB4_START_TIME  
 ,TAB4_dedup.end_time AS TAB4_END_TIME
FROM TAB1
LEFT JOIN TAB2_dedup ON TAB1.billId = TAB2_dedup.billId
LEFT JOIN TAB3_dedup ON TAB1.billId = TAB3_dedup.billId 
LEFT JOIN TAB4_dedup ON TAB1.billId = TAB4_dedup.billId 
LIMIT 10;

• 针对关联键类型隐式转换场景：创建临时表时显式将billId这类关联键定义为VARCHAR(64)类型，不要依赖CTAS的自动类型推断，从根源避免高精度数值类型的出现。
• 临时绕过方案：如果暂时无法调整JOIN逻辑，可以先在查询前执行SET enable_result_cache_for_session = off;，同时增加时间范围等过滤条件缩小参与JOIN的数据量，也能临时规避内部计数溢出问题，但该方法不能根治，最终还是要解决join扇出问题。

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