有趣的是，我一直认为如果你引用另一个 Dune 查询，那会非常低效，因为 Trino 优化器不会将外部查询和当前查询一起规划。 但事实证明，它是可以的。 我有查询 A：一个供应/提取 Morpho 市场的表。这是完整的事件日志，所以应该相当庞大。 然后是查询 B，它引用了查询 A，并在一个特定的 market_id 上进行过滤。 结果发现 Trino 仍然足够聪明，可以在查询 A 上进行谓词下推（这是一个 fancy 术语，意思是尽早过滤）。简单来说，它将我的 market_id 过滤器转移到了查询 A，即使过滤器是在查询 B 上应用的。 我不确定对于更复杂的查询，Trino 是否会做同样的事情。但这意味着： 你可能不需要在基础表上进行预优化或提前过滤。如果你的过滤器在最后一公里表上，这些表通常用于制作仪表板，Trino 能够将过滤器向上推送（真是奇怪的一句话）。 起初我对此感到相当担忧，并且有点过度优化。但警告是，你只能在预期下游表会有某种过滤的情况下这样做。因为如果你不在上游表上进行这种优化，成本会非常高。 当然，优化中的标准规则适用，比如如果你在过滤特定值之前进行窗口函数，那么这会让你很麻烦，因为你会在整个数据集上进行窗口函数处理。这可不好。 所以，查询的设计确实取决于下游表的预期用例。 不确定我是否说得通，或者这是否正确。也许有人可以检查一下。这真的很酷。