把一份工作拆成三张便签，不代表要把原材料重读三遍。BigQuery里的CTE（Common Table Expression）也类似：它只是用WITH给子查询临时起名，让SQL更容易分步阅读，并不必然生成临时表或重复处理数据。
一位初级数据工程师在Reddit描述：源表超过30GB，查询新增三层CTE后，BigQuery给出的成本估算只增加几百MB、最多不到5GB。这个现象并不奇怪。查询优化器——数据库自动改写SQL、安排省资源路线的机制——可能合并步骤或提前过滤数据。因此，CTE数量不是成本的可靠代理。
真正该看的是执行计划，也就是数据库实际扫描、连接和聚合数据的路线图：同一份中间结果是否被重复执行，读取了多少字节。少选不需要的列、尽早按分区过滤，通常比单纯少写几层CTE更直接。需要注意，这里只有发帖者的个案描述，未提供完整执行计划或实际账单。