本系列第 1/3 篇 · 论文雷达 · 下一篇 · 对照：Umbra · 现代硬件

读完带走

• 优化对象已从“单个算子更快”扩展到中间表示、数据子集、候选反馈与后续维护；FFX / SplitJoin / Enzyme / HATS 解决的约束不同，不能用 GPU / LLM / 增量计算一类标签互相替代。
• 工程上应优先问：少生成了什么、为谁付了账、何时失效。第六节的成本对照表是本文的阅读脊柱。
• “最新”只覆盖本稿检索窗口；2026-10-18 补检未发现足以改写主线的、截止日后新增硬证据（详见第一节检索窗口更新）。
• 延续 Umbra 研究路线 与 数据库系统论文精读：本文补机制边界与可组合实验，不据此判断领域占比。

一、检索口径与阅读深度

原稿检索截止 2026-09-19，来源为 VLDB 2026、SIGMOD 2026、OSDI 2026、FAST 2026、CIDR 2026、SOSP 2025 的官方目录，再回原文 / 作者页 / 出版方摘要。VLDB↔PVLDB、SIGMOD Research↔PACMMOD；会议与期刊时间戳不可混读（如 APQO 期刊日期 2025-12、归属 SIGMOD 2026；FFX 的 arXiv 上传日不等于首次发表日）。未穷尽 PVLDB v20 与 2027 已接收稿。

未运行 artifact；文中数字来自作者报告，简化例子为说明用构造。

检索窗口更新（2026-10-18）

对因子化执行、自适应 / 分片 Join order、学习优化器生产部署、IVM / 布局维护等同主题，在 2026-09-20 至 2026-10-18 补检 SIGMOD / VLDB 官方目录与可访问 PDF / arXiv。未发现足以改写本文主线主张的、明确落在该窗口内的新增硬证据。 以下条目仅作同主题对照，不升格为“截止日后最新进展”：

若后续 PVLDB / PACMMOD online-first 出现同主题全文，应先核对发表时间戳，再决定是否并入第六节成本表。

二、查询执行：优化生成了什么，而不只是处理得多快

执行效率不仅取决于处理速率，还取决于是否生成了不必要的中间数据。表示压缩、数据划分与硬件卸载分别处理不同部分的工作量。

2.1 FFX：把重复关系留在表示里

因子化执行（Factorized Execution）通过共享结构保存重复组合，可以推迟元组展开，但必须保留 SQL 的重复次数语义。

FFX：Factorized and Vectorized Execution（SIGMOD 2026）处理的是一个经常被向量化吞吐掩盖的问题：执行器可能在高效地处理大量本来不必展开的重复值。

用一个简化例子说明。假设固定键 a 分别连接三个 b 和三个 c，且这两组选择之间没有额外约束：

1展开的中间结果：             因子化的概念表示：
2(a, b1, c1)                  a → B = {b1, b2, b3}
3(a, b1, c2)                    → C = {c1, c2, c3}
4...                           含义仍是 B × C
5(a, b3, c3)
6共 9 个组合

如果后续操作允许利用共享结构，就没有必要立即复制九份 a。这不是去重：SQL 的 multiplicity 仍然存在，只是用更紧凑的物理结构表示它。

FFX 使用 packed factorized vectors，把共享结构与批量计算结合起来，并通过 cascade update 传播层次间的过滤结果。它同时保留退回传统向量化表示的路径。论文还将紧凑表示用于语义查询中的 LLM 输入，研究序列化大小与输出质量之间的关系。

它对已有 Diamond Hardened Join 阅读路线的推进是：从“把 Lookup 与 Expand 拆开、尽量晚扩张”，进一步走向“跨算子传递什么样的中间表示”。

我的工程判断是，表示转换应成为优化器能够计价的决策。高重复、多对多连接可能从中受益；普通主外键查询未必值得承担额外结构成本。若用户最终要求全部九个组合，输出枚举仍然要发生。因子化（Factorization）能够推迟或避免不必要的展开，不能消除语义要求的输出。

2.2 SplitJoin：同一 Join order 不必适合所有数据

全局平均选择率可能掩盖键之间的连接度数差异，因此同一连接顺序（Join Order）不一定适合所有数据子集。

One Join Order Does Not Fit All（VLDB 2026）从另一个位置处理中间结果问题。

传统计划通常为整条查询选择一个 Join order。但平均选择率可能掩盖局部结构：某些连接键具有很高度数，另一些键很稀疏；适合多数键的顺序，可能在少数热点键上产生巨大中间结果。

SplitJoin 根据连接键度数等信息划分 heavy/light 部分，为不同部分选择计划，并复用现有二元 Join 引擎。研究的关键不是“发现倾斜后多开线程”，而是允许不同数据部分采用不同的连接顺序。

作者在论文社交网络查询负载上报告，DuckDB 平均获得约 2.1 倍运行时间改善和 7.9 倍中间结果缩减。其理论算法有查询结构、关系规模和划分规则等前提，实际方案则使用启发式；不能把理论最坏情况保证直接推广到所有 SQL 和实际实现。

从工程角度看，新的自由度也引入新的账单：划分需要统计和处理，可能增加扫描，优化器要搜索更多选择。若输入本来接近均匀，划分开销可能无法回收。

2.3 Prune、Split、Factorize、Expand 是四件不同的事

过滤、划分、因子化与展开分别改变输入集合、执行计划或物理表示，因此一种机制的收益不能证明另一种机制已无必要：

据此可以提出一个组合实验：在同一组重复键和倾斜查询上，逐步开启过滤、划分和因子化，观察中间行数、峰值内存、转换成本与总延迟。这个实验建议不意味着这些机制已经能够直接组合，更不意味着组合必然优于单项。

2.4 Sirius：GPU 后端的价值要从查询入口量到结果出口

复用前端可以减少 GPU 后端的接入成本，但端到端收益仍取决于搬运、覆盖与回退路径。

Sirius：Rethinking Analytical Processing in the GPU Era（CIDR 2026）探索复用现有前端、以 Substrait 对接 GPU 执行后端的方式，使用 GPU 算子库承接分析处理。

这条路线的重要性在于复用边界：SQL 前端与优化器不必随硬件全部重写，但跨边界的物理语义、数据位置和算子覆盖会成为约束。

论文单机 TPC-H 实验使用 SF100，采用跨云供应商等小时租金比较；分布式实验仅覆盖当时支持的 Q1、Q3、Q6。它提供了明确的系统原型证据，却不足以支持“GPU 已全面替代 CPU”的判断，论文租金也不是当前采购报价。

对工程评估，我更关心以下总路径：

1读入与解码 → 主机/设备搬运 → GPU 执行 → 不支持算子的回退 → 结果交付
2                              │
3                              └─ 显存不足、并发、spill

如果只量中间的 kernel，可能忽略最有决定性的成本。这与 FFX 是同一个评价问题的不同侧面：既要问每秒处理多少数据，也要问为什么要搬运和处理这么多数据。

三、优化器：从一次预测转向持续管理候选与反馈

改进候选排序不能补回未生成的计划，离线搜索也只有在后续执行中摊销探索成本才产生净收益。候选管理与反馈生命周期因此需要独立评价。

3.1 OBELISK：离线搜索的核心是如何花预算

离线计划搜索需要限制低收益候选的测量支出，OBELISK 用成本旋钮和反馈引导现有 CBO，而不是让 LLM 独立生成任意执行计划。

OBELISK（PVLDB 19(7), 2026）通过成本缩放旋钮影响现有 CBO 的候选计划，结合 Bayesian optimization、LLM 推理和历史评估信息，减少低价值或重复的探索。

在这里，LLM 参与有反馈的搜索过程；既有优化器仍然负责产生计划。Training-free 表示不需要该方案的专门训练，并不意味着没有推理费用、候选运行时间和超时损失。

它与 LOAM、Ultron 等工作的对照点，不应只剩“是否使用大模型”，而应拆成三问：候选计划从哪里来？用什么证据判断候选？探索支出由多少次后续执行摊销？

可以用下面的简化不等式表达我的工程判断，它不是论文公式：

1未来执行次数 × 单次节省
2    > 候选探索成本 + 模型调用成本 + 后续验证与失效维护成本

高频、稳定、昂贵的模板更容易满足这个条件；一次性查询则可能不值得进入深度离线搜索。还需要明确，当 schema、统计或引擎版本变化时，历史赢家是否继续有效。否则离线优化得到的资产，也可能成为长期回归的来源。

3.2 APQO：缓存里的计划增加后，模型怎么办

计划集合变化会改变参数到候选的映射，固定类别预测器不能直接假设旧输出空间仍完整。

APQO：An Adaptive Framework for Parametric Query Optimization（PACMMOD 2025，SIGMOD 2026）关注参数化查询和变化中的计划集合。

根据出版方摘要，APQO 同时使用参数和计划表示，通过离线预训练与在线校准适应动态计划缓存和分布变化。它所处理的结构性问题是：如果预测器只是把参数映射到固定计划类别，那么新增一个计划，就可能改变原来的预测任务。

这值得接在 Kepler、ScalePQO 后阅读。比较时需要固定问题口径：候选集相同吗？新增计划需要多少样本？参数分布变化后多久恢复？校准的执行费用如何计入？

本轮尚未核对 APQO 全文实验，因此不能根据“foundation model”这个名称推导任意数据库的零样本迁移能力。它在本文中提供的是下一步阅读的问题定位。

3.3 把学习优化器拆成四个可独立检验的部分

学习优化器的候选生成、评价、反馈和失效处理可以分别失败，因此预测精度不足以单独解释计划质量：

这个拆分也方便接入数据库测试：选择合法计划与判断哪个计划更快是不同问题；模型置信度不能代替结果正确性验证。

四、存储引擎：卸载之后，瓶颈和债务去了哪里

卸载一个阶段只是转移工作位置，网络、上游缓冲和后台积压仍会限制系统。评估必须覆盖完整写入、读取与恢复路径。

4.1 O3-LSM：完整写路径不能只看 compaction

仅卸载压实（Compaction）无法消除 memtable 和 flush 瓶颈，O3-LSM 因而扩展到三层写入路径。

O3-LSM（SIGMOD 2026）把卸载范围扩展到 memtable、flush、compaction 三层，并利用 key-range shard 暴露并行度（Degree of Parallelism），同时考虑读委托与缓存。

这解释了一个容易忽略的现象：compaction 从计算节点搬走后，写入吞吐仍可能被 buffer 容量、flush 或网络限制。优化一个阶段后，剩余阶段占据关键路径，系统并不会自动变成可无限扩展的写入服务。

我的阅读重点是把数据路径和可靠性边界分别画出来：

1写入接收 → memtable → flush → 文件与 compaction
2   │           │         │             │
3   └─ ACK      └─ 位置   └─ 资源调度   └─ 读放大与恢复

图中是需要核对的职责，不是对论文 ACK 协议的复述。实际采用此类设计前，应明确：确认写入时哪些副本已满足持久性？远端内存失效如何处理？网络饱和时谁进行反压？卸载后读路径付出了什么代价？

因此，不能把特定网络与内存池环境中的最大吞吐改善，直接换算成普通部署的收益。

4.2 HATS：前台延迟与后台积压属于同一个问题

压低后台工作可短期改善读延迟，却可能增加后续读放大，HATS 将前台读分配与后台压实调度共同考虑。

HATS（FAST 2026）在 Cassandra 上联合考虑粗粒度读分配、细粒度副本协调和 compaction 速率控制。

它的启发在于两个局部最优会冲突：只平衡前台读，可能把请求送到正受后台任务干扰的节点；只为当前读延迟压低 compaction，又会让积压和读放大继续增加。

这可以用一个自定义的时间序列例子理解：今天暂停维护，P99 降低；随后文件或层级重叠增加，同样一次读取要承担更多工作；积压最终集中偿还，尾延迟（Tail Latency）重新升高。第一阶段的“优化”可能只是把成本推迟了。

因此我会同时记录四条曲线：前台延迟、后台资源使用、维护积压、读放大。只有前台变快且积压保持可控，才更接近持续收益。

这条路线与分析系统中的后台 Merge 有可借鉴之处，但 Cassandra 的副本路由不能直接移植到文件合并系统。应先建立资源争用和维护积压的对应关系。

4.3 LogDrive：持久性与顺序可以分别设计

持久化字节与提供全局有序日志是不同职责，LogDrive 和 AtomicLog 的分层使二者可以独立组合。

The LogDrive: Composable Durability for Cloud-Based Shared Logs（OSDI 2026）将持久性底座 LogDrive 与提供有序共享日志语义的 AtomicLog 区分开，Conflux 再基于它们实现复制状态，用于 Confluent 的元数据服务。

这种职责分离允许系统组合底层云存储，而不把持久化与排序固定在同一种服务实现中。它并没有取消一致性协议。

对云数据库，元数据的请求费用、batch 方式和恢复路径同样会影响总体成本。把低容量单价等同于低系统成本，往往会漏掉高频小请求和协调工作。阅读论文中的成本优势时，必须保留服务类型、负载和延迟 SLA 的前提。

4.4 Mantle：快速路径与权威状态分别放在哪里

目录查询的索引路径可以与权威元数据分离，但更新一致性和恢复仍需协议支持；当前核对片段只足以讨论职责划分。

Mantle（SOSP 2025）值得接在 HopsFS、Tectonic 后面阅读。

本轮核对的作者正文片段描述了分片 TafDB 与每个 namespace 的轻量 IndexNode 的分工：海量权威元数据与目录快速查询路径不必采用同样的组织方式。层次目录看似只是路径字符串，实际涉及多轮解析、热点和更新争用。

这给下一轮精读留下三个具体问题：rename 如何影响索引和缓存？副本读允许什么一致性边界？故障后怎样重新建立快速路径？这些问题需要全文协议支持，本文不把它们当作已核实的机制。

五、增量计算：决定维护什么、何时维护、维护到哪里

小变更不保证低维护成本，变化命中的历史状态和下游传播仍可能扩大工作量。增量视图维护（Incremental View Maintenance，IVM）与布局维护也需要区分。

5.1 Enzyme：单个视图的最优选择可能让下游更贵

上游刷新方式会改变下游收到的变化，因此单个视图最便宜不一定使依赖图总成本最低。

Enzyme: Incremental View Maintenance for Data Engineering（SIGMOD 2026 Industry）将增量维护放回真实的数据工程流程：规范化计划、识别可用刷新策略，再结合历史执行反馈估算成本。

对物化视图（Materialized View，MV）依赖图，上游采用全量重算，即使在本节点更便宜，也可能向下游产生更多变化；因此逐视图选择最便宜策略，未必等价于全图最优。

用一个虚构数字例子说明，数字不是论文实验：

表中真正的变量不是“8 对 10”，而是上游选择改变了下游输入状态。实际系统是否产生这种变化流，取决于刷新和变更捕获语义，不能假设所有全量刷新都有相同后果。

论文 TPC-DI 的八个案例中，成本模型选对七个；作者也将完整成本模型的论述留给后续工作。这意味着它提供了重要方向，却不能据此重建整个生产实现，更不能得出增量永远优于全量的结论。

对自己的实验，我会在 delta 行数之外记录：变化命中的历史状态规模、删除比例、join 扇出、扫描与写回、下游变化大小和恢复成本。小 delta 不一定意味着小工作量。

5.2 WAIR：维护结果之外，还可以增量维护布局

布局维护的收益来自未来扫描减少，而不只是文件排列更整齐。WAIR 根据工作负载选择值得支付重写成本的边界区域。

Workload-Aware Incremental Reclustering in Cloud Data Warehouses（SIGMOD 2026）讨论的是布局维护策略，而不是 SQL 结果的 IVM。

WAIR 将 clustering key 的选择与 reclustering policy 区分开，关注查询范围边界上的 micro-partitions：它们与谓词部分相交，可能导致额外扫描；完全位于查询范围内部或外部的分区，对这个谓词未必值得重新整理。

例如，为解释边界扫描而假设查询范围为 [40, 60]：

1分区范围       与查询的关系          对这个查询的直接含义
2[0, 30]        完全在外部            可被范围统计排除
3[25, 55]       部分相交              扫描中含有不需要的数据
4[50, 80]       部分相交              扫描中含有不需要的数据
5[85, 100]      完全在外部            可被范围统计排除

这是简化示意，不是 WAIR 完整算法。它说明布局“是否整齐”不是最终目标，未来扫描能省多少才是。历史 workload 能否代表未来，也因此成为关键假设；论文理论成本界不能脱离其模型条件使用。

5.3 AutoLiquid：选什么 key，与重写哪些文件是两个层次

选择聚簇键与安排文件重写控制不同层次，比较 AutoLiquid 与 WAIR 前需要先核对各自目标和作用域。

AutoLiquid: Autonomic Data Layout Optimization for the Databricks Lakehouse 已在 VLDB 2026 Industry 目录中提供正式论文入口。此前阅读笔记把它标为公开设计预读，本轮全文提取仍不稳定，因此维持这个证据等级。

公开材料中的 workload 观测、候选 key、抽样验证和应用过程，可以用来提出它与 WAIR 的分工问题：前者帮助讨论“选择什么布局方向”，后者帮助讨论“如何逐步支付重写成本”。两者是否能直接组合，仍需核对各自目标函数与假设。

目前不应补写未经核实的内部阈值、曲线结构或完整控制策略。下一步阅读产物应是一张决策依赖图，而不只是把两个系统归入“自动聚簇”。

5.4 Semirings：复杂度结论首先依赖语义

维护集合存在性、重复次数或来源注释所需的状态不同，不能在未说明半环（Semiring）和更新条件时引用同一复杂度结论。

The Role of Semirings in Incremental View Maintenance 是本轮补充的预印本，v2 更新于 2026 年 9 月 12 日，尚未核实正式会议归属。

论文研究 semiring-annotated 数据库的 insert-only 维护，对特定查询类和半环条件给出复杂度分类。它提醒我们：讨论更新代价之前，要先明确维护的是集合存在性、重复次数，还是带来源的注释。

直观上，同一个结果元组出现两次，在集合语义中仍只是“存在”，在 bag 语义中却有不同 multiplicity；如果需要保留来源，维护的对象又会变化。这是理解问题的例子，不是对论文定理的替代证明。

本轮只核对摘要与定理陈述，因此不将受查询结构、半环性质等条件限制的结果推广到删除、任意 SQL 或外连接（Outer Join）。它适合作为 DBSP 阅读后的理论补充，帮助列清楚语义前提。

六、成本模型对照（阅读脊柱）

主张： 中间表示与状态维护会改写后续工作量，成本不能止于当前算子的加速比。
机制： 把账目拆成“一次执行”与“一段运行”，再按论文方向对齐新增决策对象。
适用： 比较不同研究路线时做速览；选型评审时作为检查清单。
不适用： 不可当作可直接相加的统一耗时公式，也不是某篇论文的官方模型。

 1一次执行的代价
 2  = 访问与传输
 3  + 算子计算
 4  + 中间表示及转换
 5  + 结果交付
 6
 7一段时间内的系统代价
 8  = 查询执行
 9  + 候选探索与反馈采集
10  + 状态和布局维护
11  + 变化向下游传播
12  + 失败恢复与重新验证

项与项会耦合：因子化改变中间规模，布局改变未来扫描，后台维护改变前台竞争，上游刷新改变下游输入。研究价值在于识别并控制这些相互作用，而不是把加速比并列相加。

速览时优先问四句：在哪些负载上退化？回退固定成本多少？反馈多久过期？把窗口拉长后后台是否仍稳定？ 平均加速比只是其中一个切面。

七、下一步阅读与实验路线

下一步应优先复现有明确机制和可构造对照的工作，避免同时组合多个未验证改动。可以按以下三个阶段推进。

第一阶段：先打通中间结果与维护代价。 精读顺序为 SplitJoin → FFX → Enzyme → WAIR。前两篇回答执行时如何减少中间工作，后两篇回答重复运行时如何减少维护工作。配套实验分别采用有倾斜的多表 Join 与两级 MV DAG，并保留均匀数据、低重复数据和全量重算作为对照。

第二阶段：把反馈和资源竞争补进系统模型。 阅读 OBELISK → APQO，以及 O3-LSM → HATS。优化器实验计入候选执行和校准预算；存储实验同时观察前台 P99、后台积压和恢复到稳态的时间，避免只比较短时间吞吐。

第三阶段：补齐云端状态与语义边界。 阅读 LogDrive → Mantle，并将 Sirius 与 Semirings 分别作为硬件路径和理论条件的专题。AutoLiquid 的正式全文核对也在此阶段补齐，再与 WAIR 比较完整决策流程。

跨论文组合仍需单独验证：FFX 与 SplitJoin 的收益不能直接相乘，Enzyme 与 WAIR 的目标函数也不能默认兼容。APQO、Mantle、AutoLiquid 和 Semirings 保持前文声明的有限阅读等级；补齐全文与实验条件后，才能据此提出实现细节或性能比较。

附录：湖仓与执行正确性（工程对照，非会议同级）

检索补充窗口至 2026-10-18。下列条目来自近期引擎 / Iceberg 材料核对，不抬升为与 SIGMOD/VLDB 主文同级主张；用于标出生产路径上的正确性边界，并链到 Join / Dynamic Filter 系列。

A.1 单调快照时间戳（Iceberg，已合）

同分支 snapshot 的 timestamp-ms 须严格大于父快照：spec 与实现已合入。价值在于让时间旅行与增量消费有可比较的全序，而不是依赖墙钟巧合。笔记层仍标 needs-review，本文只记录「约束已进主干」这一事实。

A.2 AMT 基线合仓（非 format adoption）

AMT 相关基线 PR 已合入（公开讨论口径 18+1）。这是实现与测试基线推进，不是 format v4 的 adoption 宣告；阅读时勿与「格式已默认启用」混淆。

A.3 DuckDB：spill 后 Join filter 静默丢行（已修）

外部 hash join 在 spill 后若 Bloom 只含第一轮 build 域，可能静默丢行（#25702）；后续 #25718 / #26959 已修。机制提醒与 Dynamic Filter / Runtime Filter 相同：filter 域必须覆盖全部 build 分区，否则假阴性会改写结果。详细路径见 Join 系列与 Dynamic Filter 正确性篇；本附录不展开源码。

跟踪清单（待审，正文不展开）

Spark External Lookup Join（SPIP/DISCUSS）；Spark EXPLAIN COST on VIEW、恒 false FULL JOIN 改写；Doris SQL plan management；TiDB CBO late materialization；Trino Iceberg MERGE 隔离；ClickHouse Iceberg 读路径漏新 commit；Iceberg FILE 类型投票 / DV 行级并发 / promotable types / KMS vending。

参考文献

以下保留正式出版入口或本轮核对的作者原文；会议年份与预印本状态按前文口径区分。

1. Factorized and Vectorized Execution: Optimizing Analytical and Semantic Queries over Relations. SIGMOD 2026.
2. One Join Order Does Not Fit All: Reducing Intermediate Results with Per-Split Query Plans. VLDB 2026.
3. Rethinking Analytical Processing in the GPU Era. CIDR 2026.
4. OBELISK: Efficient Offline Query Planning with Bayesian Optimization-Informed Language Model Reasoning. PVLDB 19(7), 2026.
5. APQO: An Adaptive Framework for Parametric Query Optimization. PACMMOD 3(6), 2025 / SIGMOD 2026.
6. O3-LSM: Maximizing Disaggregated LSM Write Performance via Three-Layer Offloading. SIGMOD 2026.
7. Holistic and Automated Task Scheduling for Distributed LSM-tree-based Storage. FAST 2026.
8. The LogDrive: Composable Durability for Cloud-Based Shared Logs. OSDI 2026.
9. Mantle: Efficient Hierarchical Metadata Management for Cloud Object Storage Services. SOSP 2025.
10. Enzyme: Incremental View Maintenance for Data Engineering. SIGMOD 2026 Industry.
11. Workload-Aware Incremental Reclustering in Cloud Data Warehouses. SIGMOD 2026.
12. AutoLiquid: Autonomic Data Layout Optimization for the Databricks Lakehouse. VLDB 2026 Industry；本文保持设计预读状态。
13. The Role of Semirings in Incremental View Maintenance. arXiv 预印本，v2 更新于 2026-09-12。
14. （同主题对照，非 09-20 后新增）The Data World Is Not Flat: Efficient Factorized Execution for Relational Systems. PVLDB 19(11), 2026. 待核对与 FFX 的路径分工。
15. （同主题对照，正式发表早于本窗口）GenJoin: Conditional Generative Plan-to-Plan Query Optimizer that Learns from Subplan Hints. PACMMOD / SIGMOD 2026。