咨询Snowflake多WITH含UNION时EXPLAIN与Profile剪枝结果不匹配问题

核心判定 #

你观察到的多WITH块场景下的展示偏差，属于Profile面板的信息采集类bug，并非实际执行阶段真的拉取了未使用的冗余字段。

• 所有复现场景中，Table Scan阶段的实际字段剪枝逻辑和EXPLAIN输出完全一致：仅读取关联所需的c_custkey字段，这也是异常场景下扫描字节数、行数和正常场景完全对齐的核心原因——执行层面根本没有产生冗余字段的读取成本。

展示偏差的产生逻辑 #

• Profile面板的字段剪枝展示信息，来自运行时执行节点在任务执行过程中实时上报的统计值，而非从静态EXPLAIN计划中同步提取内容。
• 不同查询结构下，剪枝标记的传递路径存在明显差异：
  • 单WITH、无WITH的嵌套子查询带UNION场景：字段剪枝标记会逐层下推到最底层的每一个Table Scan节点，运行时Scan节点能正常上报实际读取的列信息，Profile面板就可以正确展示剪枝结果。
  • 多WITH块、且至少一个WITH块包含UNION/UNION ALL集合运算的场景：剪枝标记仅会停留在CTE对应的集合运算层，不会穿透UNION节点下传到最底层的Table Scan节点，运行时Scan节点采集不到明确的剪枝标记，就会默认输出“读取全量表字段”的占位展示，不会体现实际生效的列剪枝信息。
• 这种展示层的信息漏采完全不会影响实际执行效率：底层存储引擎的列裁剪是存储层的硬约束，只要计划层标记了需要读取的列范围，存储层就只会返回对应列的数据，和上层展示层是否采集到对应标记没有关联。

快速验证方法 #

• 直接对比三类查询的Table Scan步骤指标：如果多WITH场景的Bytes scanned、Rows scanned数值和正常场景完全一致，即可确认实际执行没有拉取冗余字段。
• 对比三类查询的端到端执行耗时：如果异常场景的耗时没有出现数倍的增长幅度，也可佐证不存在全量读列的额外成本。

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