Redshift查询出现Nested Loop Join问题及修复咨询

1. 为什么会出现Nested Loop Join告警？ #

首先得明确：这个告警不代表你的查询一定会产生笛卡尔积——毕竟你已经明确指定了svv_table_info.table_id=stl_delete.tbl的连接谓词。触发告警的常见原因有这几个：

• 系统表统计信息过时：Redshift的查询优化器依赖表统计信息选择连接策略，但stl_delete和svv_table_info这类系统表/视图，Redshift不会自动频繁更新它们的统计信息。如果优化器误判其中一张表数据量极小，就会优先选Nested Loop Join，这种选择和实际数据分布不符时，就会触发告警。
• 系统视图的底层复杂性：svv_table_info是封装后的系统视图，它底层关联了多个系统表。优化器解析视图时，可能对连接条件的有效性判断出现偏差，误以为存在笛卡尔积风险。
• 连接字段存在NULL值：如果stl_delete.tbl或svv_table_info.table_id有NULL值，虽然你的连接条件合法，但NULL值的存在会让优化器担心出现意外的无匹配关联，进而触发告警。

2. 如何修复这个问题？ #

针对上述原因，你可以尝试以下几种方案：

方案1：强制指定连接方式（推荐）

既然优化器选的Nested Loop Join触发了告警，直接用Redshift的查询提示强制使用更安全的Hash Join或Merge Join即可，比如：

/*+ JOIN_HASH(stl_delete svv_table_info) */
select stl_delete.query, listagg(distinct svv_table_info.table,',') 
from stl_delete 
join svv_table_info on svv_table_info.table_id=stl_delete.tbl 
where stl_delete.query=1090750 
group by stl_delete.query;

或者强制用Merge Join：

/*+ JOIN_MERGE(stl_delete svv_table_info) */
select stl_delete.query, listagg(distinct svv_table_info.table,',') 
from stl_delete 
join svv_table_info on svv_table_info.table_id=stl_delete.tbl 
where stl_delete.query=1090750 
group by stl_delete.query;

方案2：更新统计信息

虽然系统表的统计信息通常由Redshift维护，但你可以手动尝试更新，帮助优化器做出更准确的判断：

ANALYZE stl_delete;
ANALYZE svv_table_info;

注意：svv_table_info是视图，可能无法直接执行ANALYZE，这种情况下直接用查询提示的方式会更高效。

方案3：过滤NULL值并缩小数据集

先通过子查询过滤掉stl_delete中无效的NULL记录，缩小关联的数据量，让优化器更清晰地识别数据分布：

select s.query, listagg(distinct t.table,',') 
from (select query, tbl from stl_delete where query=1090750 and tbl is not null) s
join svv_table_info t on t.table_id = s.tbl
group by s.query;

方案4：提前去重关联表

如果svv_table_info中存在同一table_id对应多个表名的异常情况（理论上不应该，但实际可能出现），可以先去重再关联：

select s.query, listagg(distinct t.table,',') 
from stl_delete s
join (select distinct table_id, table from svv_table_info) t on t.table_id = s.tbl
where s.query=1090750
group by s.query;

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