2026 年，智能体在企业级应用里会迎来哪些实质性突破？《2026 年 AI 与数据发展预测》白皮书已经可以下载，里面是专家的一手前瞻，想抢先接触新的工作方式可以去看看。

Optima Planning：围绕查询，还能多问一个问题

美国一家大型医疗健康科技公司的生产工作负载里，跨查询反馈把一条含 19 个连接操作的分析查询，执行时间从近两小时压到了 30 秒。怎么做到的？

此前，Optima Planning 只回答一个关于完整查询的问题：这条查询或它的某种变体，以前跑过没有？这一机制我们在上一篇博客《通过 Snowflake Optima Planning 提升重复查询性能》里讲过。现在它还能回答另一个互补的问题，盯的是查询内部的某个计划片段或单独的操作算子。

针对单条查询的反馈，回答的是一个要紧的问题：

这条查询，或者它的某种变体，之前是否执行过？

而匹配计划片段或单个操作算子，回答的是另一个互补的问题。它不看整条查询，只看查询计划中的某一部分：

这个计划片段，或者某个特定的操作算子（比如连接操作），是否曾经出现在其他已执行的查询中？

两套机制合在一起，Optima Planning 能学习的查询范围就变大了：既覆盖相同查询，也覆盖结构模式重复、但并不完全相同的查询。

工作原理

现在，Optima Planning 的匹配粒度已经细到完整查询以下，可以匹配查询内部的计划片段（比如共享视图中的连接树），也可以匹配单个操作算子（比如某个特定的连接操作）。

整体流程是这样走的：

1. 查询编译完成后，Optima Planning 会给查询计划里的每个计划片段和单个操作算子（比如某个特定的连接操作）算一个哈希值。哈希值取自优化器为这部分计划生成的输出，而不是整条查询的 SQL 文本。

2. 如果后面另一条查询里含有相同哈希值的片段或操作算子，哪怕查询其余部分完全不同，比如新加了一张此前从未参与连接的表，Optima Planning 照样能认出其中的共同部分。

3. 第一次查询执行产生的反馈，会被拿去优化第二次查询中对应的片段或操作算子。这样一来，第二条查询即便从未完整执行过，优化器也能借助该部分已有的实际执行数据来选计划，不用从零开始。

靠计划片段或单个操作算子来匹配，能找到不同查询计划之间的共同部分。但匹配成功只说明反馈信息有复用的可能，不代表一定会被采用。

Optima Planning 还会做一层智能判断：把已有的执行反馈用到新查询上，会不会造成过度泛化，也就是某些在原有上下文里成立的执行经验，换到新上下文里可能就不适用了。一旦判断反馈迁移的范围过大，这些反馈就不会被应用。

关键点在于，匹配依据是 Snowflake 优化器生成的查询计划中的片段或操作算子，而非整条查询的 SQL 文本。

这套机制并不取代针对单条查询的反馈机制。后者已经能处理同一查询的不同变体，跨查询匹配补的是它还没覆盖的场景：一条查询虽然和之前执行过的查询不同，却包含曾在其他查询中执行过的计划片段或操作算子。

两种机制的衔接很清楚：查询内部匹配在全新查询首次执行时就能起作用。同一查询第二次执行时，它就有了自己的查询身份，和其他重复执行的查询一样，后续优化交给针对单条查询的反馈机制。

Snowflake 的优化器走的是基于成本的优化路线：估算每个操作算子的输出行数，再挑预计执行成本最低的查询计划。估算一旦出现偏差，优化器可能选错连接顺序或构建侧，有时还会引发连锁反应，产生数十亿行不必要的中间结果。这个问题我们在《提升重复查询性能》和《基于真实数据优化查询计划》里介绍得更深入。

跨查询学习适用于哪些场景

为现有视图添加新的连接操作

SELECT * FROM v_customer_orders v JOIN returns r ON v.order_id = r.order_id WHERE ...  

查询是分析人员在工作负载里常用视图的基础上搭出来的，只多加了一个连接操作，这种组合此前没人跑过。拼出来的查询虽然全新、查询身份也是新的，但v_customer_orders内部的连接片段早已存在，并非第一次执行。

新报表里常出现的连接方式，可以直接沿用已有经验

SELECT c.region, COUNT(*) FROM customers c JOIN orders o ON o.customer_id = c.customer_idWHERE o.status = 'RETURNED' GROUP BY c.region  -- this exact report is new

这张报表此前没跑过，里面的列表和分组方式都是新的。可它用到的客户表与订单表连接并不新鲜——别的报表早就用过同样的连接，执行反馈已经攒下了。SELECT

逻辑一致、SQL 写法却不同的查询

FROM orders o JOIN customers c ON c.customer_id = o.customer_id   FROM customers c JOIN orders o ON o.customer_id = c.customer_id   

两个 BI 工具做出来的连接操作可能一模一样，只是表在 SQL 里出现的先后顺序相反。眼下这类 SQL 还会被当成两条不同的查询。但计划片段和单个操作算子的匹配，看的是查询计划里的算子，不是 SQL 文本FROM中子句的表排列顺序。所以这两条查询照样能共用这段连接操作的反馈信息。

上面说的几种情况，查询内部匹配都能把针对共同计划片段或操作算子攒下的反馈信息拿来复用。

用一个模拟例子来说明

还是拿上一篇博客里的餐厅例子接着讲：restaurants、menu_items、sourcing_records 和 suppliers一共四张表，靠restaurant_id、ingredient_category 和 supplier_id 进行连接。

前文提过，高评分餐厅往往只用少数几种高端食材，这些食材多出自手工生产型供应商，工业化供应商则很少涉足。这层关联分散在三张表里，只看单表统计信息根本看不出来。

下面这条查询，我们叫它查询 A：

SELECT COUNT(*)FROM   restaurants      rJOIN   menu_items       mi ON r.restaurant_id = mi.restaurant_idJOIN   sourcing_records sr ON mi.ingredient_category = sr.ingredient_categoryJOIN   suppliers        s  ON sr.supplier_id = s.supplier_idWHERE  r.guide_rating >= 1  AND  s.supply_chain_type = 'industrial';

第一次跑的时候，优化器并不知道这些数据之间的关联，连接操作因此堆出大量中间结果——在过滤条件把结果集压到几乎为空之前，已经生成了数千万行数据。

再跑一次，Optima Planning 用这条查询上一次执行留下的数据，给出了更好的查询计划：

可要是碰到一条相似、又不完全一样的查询呢？

来看查询 B。它的表连接关系和连接列与查询 A 相同，但输出列不一样，评分筛选阈值也换了，还多了一个排序操作：

SELECT r.restaurant_id, mi.menu_item_id, s.supplier_nameFROM   restaurants      rJOIN   menu_items       mi ON r.restaurant_id = mi.restaurant_idJOIN   sourcing_records sr ON mi.ingredient_category = sr.ingredient_categoryJOIN   suppliers        s  ON sr.supplier_id = s.supplier_idWHERE  r.guide_rating = 1  AND  s.supply_chain_type = 'industrial'ORDER BY r.restaurant_id, mi.menu_item_id;

这条查询优化器之前没见过一模一样的，生成高质量查询计划时就卡住了，情况和第一次执行查询 A 时一样。

结果，连接操作产生了大量中间结果，整条查询跑了约 13 秒。

有了这项新功能，查询 A 里的基数估算信息可以搬到查询 B 上用。

也就是说，查询 B 虽然是第一次执行的全新查询，优化器也能直接给出改进后的查询计划。

换上新计划后，查询执行时间降到约半秒：

对一条此前从未执行、也没有自身历史执行记录可参考的查询来说，这相当于约 26 倍的性能提升。

一个真实生产案例

下面这个查询案例来自美国一家大型医疗健康科技公司，是真实生产环境里的，能看出该功能的实际效果。

该客户执行了一条分析查询，里面包含 19 个连接操作和多个相互关联的连接谓词。这种复杂结构，传统的基数估算方法往往应付不来。

优化器给出的查询计划不够好，连接操作产生了数十亿行中间结果，查询最终耗时接近两小时。

后来的一次执行中，优化器用上了另一条结构相似但并不相同的查询提供的跨查询反馈，基数估算结果得到改善，执行计划也更优。

最终，查询执行时间只有 30 秒！

这个案例说明了跨查询反馈真正的突破之处：一条查询即使没有自己的历史执行记录，也能从其他查询的执行经验里获益。

只要它用的连接结构在工作负载的其他查询里出现过，Optima Planning 就能马上借用这些经验，哪怕这条查询是首次执行。

哪些情况下能够发挥作用

当一条真正全新的查询，与此前执行过的查询共享某个计划片段或单个操作算子时，这项能力价值最大。

Optima Planning 在查询内部做匹配，把反馈机制扩展到了不同查询之间。

尤其适用于以下情况：

• 这类查询的执行成本不低，执行计划一旦选错，就可能引发大范围扫描或连接操作；

• 还有一类查询本身是新的，比如新增了连接、表或组合，但它是在已有视图、CTE（公用表表达式）或工作负载里其他查询用过的常见连接模式上做扩展；

• 分析人员写的临时查询，沿用了多份报表中反复出现的连接模式，哪怕这份具体报表以前从没跑过；

• SQL 完全由 BI 工具或大语言模型（LLM）生成，Cortex Analyst、Tableau Pulse 就属于这种情况；

• 两个 BI 工具或 ORM（对象关系映射工具）用不同的连接顺序写出了相同的连接操作。眼下这些 SQL 仍被当作不同的查询。

面对这些场景，匹配计划片段或单个操作算子，比匹配整个查询能明显扩大查询计划优化的覆盖面。

客户怎样查看 Optima 的优化效果

在查询历史记录（Query History）的查询性能分析（Query Profile）里，客户可以通过查询洞察（Query insights）面板、统计信息（Statistics）面板，以及QUERY_INSIGHTS视图来监控 Snowflake Optima 的使用情况。完整机制的介绍见《基于真实数据优化查询计划》。

具体到 Optima Planning，客户能看到 Snowflake 在何时应用了优化洞察来改善查询计划质量。这种新匹配方式目前与其他反馈机制共用同一条客户可见提示：“This query benefits from Snowflake optima planning.”现阶段系统还没有单独的提示，用来区分反馈是来自计划片段或操作算子匹配，还是来自同一查询匹配。两种情形在 Query Profile 和QUERY_INSIGHTS中的呈现方式一模一样。

核心要点

Optima Planning 的关键在于：用更可靠的执行数据，产出更优的查询计划。

现在，单条查询反馈加上跨查询反馈，已经能覆盖工作负载生命周期里的更多情形：

• 重复执行的工作负载：对仪表板、定时报表和 ELT 数据流水线，Optima Planning 能从历史执行中学会哪些连接操作会产生大量中间结果，从而持续提升查询性能；

• 基于已有查询结构扩展的新查询：新查询在现有视图、CTE 或其他查询用过的常见连接模式上增加连接操作时，即便首次执行，也能借助已有计划片段的反馈；

• 生产环境里的实际效果：在真实生产工作负载中，跨查询反馈把一条含 19 个连接操作的分析查询，执行时间从近两小时压缩到 30 秒。

不用手动调优，也不用手动配置，就能拿到更好的查询计划。