计划片段复用将SQL查询从近两小时优化至30秒

Optima Planning新增了计划片段和单个操作算子级别的反馈机制。在美国一家大型医疗健康科技公司的生产负载中，一条包含19个连接操作的分析查询因基数估算失误产生大量中间结果，耗时接近两小时；通过跨查询复用优化经验，执行时间最终缩短至30秒。

此前，该系统主要判断某条完整查询或其变体是否执行过。新机制则进一步检查查询计划内部的片段，例如共享视图中的连接树，或某个具体的Join算子是否曾出现在其他查询中。两种机制结合后，既能优化重复查询，也能让结构相似但文本不同的新查询借用已有经验。

查询编译完成后，系统会根据优化器为各个计划片段和算子生成的输出计算哈希，而不是直接比较SQL文本。后续查询即使增加了新表、改变输出列或采用不同的表排列顺序，只要其中存在相同的计划结构，就可能复用此前执行产生的基数和运行反馈。系统还会评估反馈迁移是否过度泛化，判断新上下文不适用时将放弃复用。

这一能力适用于多种场景，例如在已有视图上增加此前未执行过的连接、在新报表中复用其他报表使用过的客户表与订单表连接，或处理不同BI工具生成的等价SQL。针对单条查询的反馈机制仍然保留：新查询首次执行时可以使用片段级反馈，第二次执行后则会建立自身的查询身份，并由单查询反馈继续优化。

模拟示例使用餐厅、菜单、采购记录和供应商四张表。查询A首次执行时，由于优化器不了解评分、食材类别和供应商类型之间的关联，连接过程中产生数千万行无效中间结果；再次执行时，系统可利用历史数据生成更优计划。查询B虽然使用相同的连接关系和列，但增加了排序、改变了输出列和过滤条件，首次执行仍耗时约13秒。

借助计划片段级反馈，查询A中积累的基数估算信息可以迁移到查询B。这样，查询B无需先建立自身历史记录，就能在首次执行时生成改进后的计划，执行时间降至约0.5秒，相比原先提升约26倍。

在真实案例中，客户的分析查询包含19个连接及多个相互关联的连接谓词。传统估算无法准确反映数据关系，次优计划导致连接操作产生数十亿行中间结果，查询耗时接近两小时。后续执行借助跨查询反馈改进计划，最终将耗时压缩到约30秒。