Amazon Redshift子计划哈希表不存在报错及查询改写疑问

报错信息 #

error: Assert
code: 1000
context: ht0_3 != NULL - Hash table for subplan does not exist.

问题背景 #

在Amazon Redshift中运行数月的视图突然触发上述断言错误。该查询包含3个CTE，每个CTE从单表选取去重行后进行关联；单独执行每个CTE均正常，但关联操作时触发报错。移除其中一个CTE可规避问题，但业务需要该数据。

原报错查询 #

CREATE TABLE bad_table AS (
    SELECT DISTINCT
        t.table_schema,
        t.table_name,
        t.column_name
    FROM svv_columns t
    WHERE true
        AND t.table_name not like '%test%'
        AND t.table_schema in ('table_1','table_2', ... , 'table_30')
)

改写后正常运行的查询 #

CREATE TABLE failing_table AS (
    SELECT DISTINCT
        t.table_schema,
        t.table_name,
        t.column_name
    FROM svv_columns t
    WHERE true
        AND t.table_name not like '%test%'
        AND (t.table_schema in ('table_1', ... , 'table_10')
            or t.table_schema in ('table_11', ... , 'table_20')
            or t.table_schema in ('table_21', ... , 'table_30'))
    )

补充：相同的过滤条件在包含这30个表及更多表的CTE中正常运行，仅单独包含这30个表的CTE触发报错。

问题解答 #

1. 未修改数据库设置或视图本身，为何视图突然触发该报错？

• 核心原因是Redshift查询优化器生成了有缺陷的执行计划。即使视图和数据库配置未改动，当底层表的统计信息过期、数据分布/量级发生显著变化（比如某schema下的表数量大幅变动、数据倾斜加剧），优化器会重新计算执行计划，此时可能触发哈希表初始化相关的断言bug。
• 另外，Redshift后台推送的小版本补丁或优化器逻辑微调，也可能在特定查询场景下引入临时异常，刚好命中你的查询模式。

2. 为何同一AND条件在单IN子句时报错，拆分为多IN子句用OR连接时正常？

• 单IN子句包含30个值时，优化器可能选择了哈希连接作为核心执行策略，但该场景下哈希表的创建/初始化逻辑出现异常；拆分后多个小IN子句通过OR连接，优化器会调整执行计划（比如转为嵌套循环、分段过滤后再连接），避开了触发bug的代码路径。
• 小批量的IN列表会让优化器判断更适合采用低复杂度的过滤或连接方式，从而生成了更稳定的执行计划，绕过了原计划中的哈希表初始化问题。

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