Aphasia

本文讨论的是一种通用的数据库研究方法，而不是某个具体数据库的产品设计。公开资料核对截至 2026-09-30；论文实验、项目文档、源码事实和本文观点会尽量分开表述。

引言：真正稀缺的不是信息，而是可复用的判断

数据库研发人员从来不缺少信息：每周都有新的 Release Note、技术博客、论文、Pull Request、Issue、Benchmark 和会议分享。问题是，信息数量的增长并没有自动转化为更好的优化器和执行引擎。

当我们看到“某引擎增加了自适应 Join”“某论文报告了 3 倍加速”“某个 PR 消除了一个 Exchange”时，真正需要回答的是：

• 它解决的究竟是什么查询形态和资源瓶颈？
• 这个机制依赖哪些语义、统计、物理属性和执行模型？
• 目标系统是否已经通过别的路径解决了相同问题？
• 源码里“存在代码”是否意味着规则可达、默认启用并会被代价模型选中？
• 论文的实验条件能否迁移到另一种数据分布、硬件和工作负载？
• 哪些结论已经有证据，哪些只是值得进一步验证的假设？

一次临时搜索可以回答其中一两个问题，却很难积累长期判断。几个月后，同一个机制换了名字、换了发布渠道再次出现，团队可能重新完成一遍阅读；曾经因为语义错误而被否定的建议，也可能被新的模型重新包装后再次生成。

因此，我更愿意把“优化研究平台”定义为：

一个持续接收外部证据、维护目标系统已知能力、生成可反驳研究问题，并让专家判断能够版本化沉淀的研究闭环。

它不等于新闻聚合器，也不等于自动生成 Wiki，更不等于让一个 Agent 自主修改优化器。平台的核心产物不是文章数量，而是带版本、前提、反例、证据位置和结案条件的研究记录。

1. 先把问题收敛：平台究竟要交付什么

1.1 从“资讯摘要”升级为“研究判断”

一份资讯摘要通常回答“发生了什么”；一份研究记录还需要回答“为什么值得关注，以及我们还不知道什么”。两者的差别可以放在一条逐步增强的链路上：

 1网页、论文、PR、源码
 2        │
 3        ▼
 4可定位的事实：谁在什么版本声明或实现了什么
 5        │
 6        ▼
 7机制解释：输入、状态、算法、控制点与输出如何变化
 8        │
 9        ▼
10适用边界：语义前提、执行模型、数据与资源条件
11        │
12        ▼
13目标系统映射：已覆盖、部分覆盖、局部缺口、未知或不适用
14        │
15        ▼
16最小研究问题：下一步核对什么，何时可以结案

最后一层非常重要。没有结案条件的“建议进一步研究”，往往只是把阅读任务推给下一个人。一条好的研究问题应该足够小，例如：

固定版本下，外连接简化能否识别包含确定性 cast 的拒绝空值谓词？如果已有正反测试和规则调用链覆盖该形态，本轮研究结案；如果 guard 明确拒绝，再分析是语义限制还是实现缺口。

1.2 什么结果算成功

研究平台的成功输出不一定是“发现新优化点”，还可以是：

• 目标系统已经覆盖该机制，外部变化没有新增信息；
• 目标系统只覆盖其中一类条件，局部边界值得核对；
• 两个系统执行模型不同，当前机制不可直接迁移；
• 外部资料没有给出足够细节，结论保持未知；
• 旧建议因为新版本、新反例或新实验而失效。

允许不生成建议，是质量控制的一部分。如果系统被要求每周固定产出十条“优化机会”，它最终一定会把重复信息、未知状态和性能猜测包装成建议。

1.3 明确非目标

第一阶段通常不应承诺：

• 自动证明所有 SQL 重写在完整 SQL 语义下等价；
• 从静态源码推断真实生产收益；
• 部署所有对比引擎并完成同条件 Benchmark；
• 发现目标系统的全部优化缺口；
• 根据外部文章自动修改并上线数据库代码；
• 让引用数量或模型置信分替代专家判断。

这些不是永远不做，而是需要在证据、隔离环境、评测和变更治理成熟以后独立建设。

2. 关键名词：避免在同一个词下讨论不同东西

很多平台设计的歧义，不来自算法，而来自名词没有对齐。下面给出本文采用的定义。

2.1 Source、Event、Fact、Mechanism 与 Finding

为什么不能直接把网页当 Event？同一变化可能先出现在设计文档，后进入 PR，再进入 Release，最后被博客介绍。四份 Source 指向一个 Event，但对应不同成熟阶段。如果每篇文章都被当成新事件，平台会持续制造“假新意”。

2.2 Provenance 与 Evidence

Provenance，来源谱系，回答一条结论从哪里来、经过哪些转换：原文位置、抓取时间、提交版本、提取任务、人工修订和最终报告之间如何关联。

Evidence，证据，回答这份材料能够支持什么结论。链接存在并不代表链接支持句子；源码存在也不代表路径可达。来源谱系解决追踪问题，证据分析解决推理边界问题。

一个事实最好拥有这样的最小引用结构：

 1{
 2  "claim_id": "F-2026-0042",
 3  "claim": "规则在配置关闭时不参与当前优化批次",
 4  "source": {
 5    "type": "source_code",
 6    "repository": "example/engine",
 7    "commit": "<full-commit-id>",
 8    "path": "optimizer/rules/example_rule.cc",
 9    "symbol": "ExampleRule::check"
10  },
11  "support": "direct",
12  "limitations": ["未排除其他等价实现路径"]
13}

行号适合阅读，但代码演进后会漂移；commit、path 与 symbol 的组合通常更稳定。网页则至少保存 canonical URL、抓取时间、内容哈希和支持结论的片段。

2.3 目标系统能力档案

能力档案不是自动生成的项目百科，而是围绕研究决策维护的最小已知状态。它记录：

• 已知能力及固定版本证据；
• 适用条件与明确限制；
• 架构接口和责任边界；
• 历史建议、否定原因与待复核项；
• 当前最有价值的研究主题。

它可以从几十个 Markdown 条目开始，不需要先把整个仓库放入知识图谱。档案的意义是为反向检索提供记忆：看到外部“消除 Shuffle”的文章时，先搜索目标系统是否通过物理属性、局部 Shuffle、bucket mapping 或别的阶段实现了相同效果，而不是直接生成“应该支持 Shuffle 消除”。

2.4 RAG、Embedding、代码图谱与 Agent

这几个词经常被混在一起：

• RAG（Retrieval-Augmented Generation）：先检索相关资料，再让模型基于检索结果生成答案。它改善上下文相关性，但不自动保证事实正确。
• Embedding（向量表示）：将文本或代码映射为向量，用距离近似语义相似。适合召回同义描述，不擅长独立证明控制流和版本关系。
• 代码图谱：将 symbol、definition、reference、call、inheritance、file 等关系组织成图。它能辅助导航，但边的精度依赖语言前端和构建信息。
• Tree-sitter：增量解析框架，可获得语法树；语法关系不等同于经过类型解析的精确调用关系。
• SCIP（Source Code Intelligence Protocol）：一种代码索引协议，可以表达符号和引用；是否能得到完整索引，仍取决于语言 indexer 与构建环境。
• Agent：能够在约束下多步选择工具、观察结果并继续行动的执行器。Agent 提高探索能力，也扩大了权限、成本、可重复性和提示注入风险。

这些组件没有谁天然“更高级”。关键词搜索对精确配置名最好；语法树适合定位规则结构；精确代码索引适合跨文件符号引用；向量检索适合同义机制召回；Agent 适合答案路径无法预先写死的研究任务。成熟系统通常组合它们，而不是用一种检索方式替代所有方式。

2.5 正确性、可达性与收益是三个问题

对一条优化规则，应依次区分：

1. 语义正确性：变换是否保持约定的查询语义？
2. 计划可达性：当前实现、规则顺序和配置能否生成该计划？
3. 性能收益：代价模型是否会选择它，并在目标工作负载上更快或更省资源？

形式化证明可以加强第一个问题，源码和测试帮助回答第二个问题，运行实验主要回答第三个问题。任何一层都不能代替另外两层。

2.6 形式化方法：Lean、TLA+ 与 SQL 等价性工具分别解决什么

“形式化验证”不是一种可以笼统接入平台的万能能力。不同工具处理的对象并不相同：

• Lean 是交互式定理证明器。研究者可以定义关系代数或 SQL 子集的语义，再证明某个改写在给定前提下保持等价。这里必须明确采用 set 还是 bag semantics，如何解释 NULL 与三值逻辑，以及是否考虑顺序、溢出、异常和非确定函数。证明只覆盖被建模的语义，不自动证明真实数据库实现没有缺陷，也不回答改写是否更快。
• TLA+ 更适合描述并发协议和状态迁移，例如调度器状态、动态扩缩容、Spill/恢复流程和任务重试。模型检查能够在有限状态空间中搜索违反安全性或活性约束的执行路径；“没有找到反例”依然不等于对任意规模实现完成了数学证明。
• SQLSolver、Cosette 一类领域工具把特定 SQL 子集、约束和等价性判断封装得更直接。它们返回 UNKNOWN 时，应保留“当前模型无法判断”的含义，不能把它偷换成“不等价”，更不能把支持子集中的结论外推到完整方言。

因此，形式化工具适合处理高价值、语义边界清晰的改写争议，或故障代价很高的并发协议。它们不适合成为平台第一阶段的必选基础设施。更现实的顺序是：先让前提、反例和证据结构化；当某类争议反复出现，再为它建立足够小、可维护的形式化模型。

3. 现有项目解决了哪些子问题

3.1 仓库理解和资料采集

DeepWiki 官方文档已经表明，仓库 Wiki 可以通过配置显式提供背景和页面结构。这是一个重要信号：大型仓库研究不应完全依赖模型自行猜测阅读范围，领域术语、关键目录和已知盲区应当由研究任务显式提供。

但“生成代码说明”与“发现优化机会”之间还有很长距离。后者需要版本判断、跨系统能力映射、反例、历史结论和工作负载相关性，这些通常不在通用代码 Wiki 的责任范围内。

项目入口：DeepWiki-Open、CodeWiki、CodeGraphContext、Miniflux、changedetection.io。

3.2 SQL 改写、证明与实验框架

这些项目处于不同证据层级，不能被排成一张“智能程度排行榜”。等价性工具回答语义问题，SQLancer 通过执行寻找缺陷，PostBOUND 组织实验，R-Bot 关注证据辅助的 SQL 改写。研究平台应调用合适的工具回答具体问题，而不是强迫一个模型同时扮演定理证明器、执行器和性能裁判。

项目入口：R-Bot、WeTune、SQLSolver、Cosette、SQLancer、PostBOUND。

3.3 三个工业/研究案例真正说明了什么

2025 年的 R-Bot 论文描述了多源 rewrite evidence、结构与语义混合检索、逐步规则选择，并报告了华为及客户部署。它支持“领域证据可以约束 LLM 改写”这一方向，却不证明一个通用情报平台可以直接产出正确的优化器补丁。

Microsoft 的 QO-Advisor将更充分的计划探索放入离线流水线，并在论文所述 SCOPE 场景中讨论预算、可解释 steering 和回归控制。这里值得借鉴的不是某个模型，而是把探索、验证与生产执行隔离，并为坏决策保留可逆路径。

CIDR 2026 的 Leveraging Query Optimizers to Verify the Soundness of LLM-based Query Rewrites基于真实企业查询讨论 LLM rewrite，强调语义等价性是实际采用的主要障碍，并提出利用优化器已有能力验证等价性；作者还观察到，模型生成的 rewrite 可以反向暴露优化器缺失的候选变换。

这三个案例共同证明了一些组成方法具有价值，但没有证明“持续抓取外部资料，就能稳定产生高收益优化”。平台仍然需要自己的目标能力档案、时间切分评测和专家反馈。

4. 精确比较引擎：单位不是规则名，而是有条件的能力

4.1 为什么规则数量没有比较意义

一个优化能力可能分散在：

• Analyzer 或 Binder 的表达式规范化；
• logical rewrite rule；
• Memo 中的 exploration rule；
• property derivation 与 Enforcer；
• physical implementation rule；
• cost model；
• Runtime 自适应路径。

同名规则也可能覆盖完全不同的语义。例如“Predicate Pushdown”可以指过滤穿过 Project、Aggregate、Window、Join 或 connector boundary；每种情况的确定性、NULL、异常行为和列映射前提不同。只比较类名或规则数量，会同时产生漏报和误报。

更可靠的比较单位是：

在条件集合 C 下，系统通过阶段 S 和机制 M，将计划 P 转换为 P′，并产生可观察结果 O。

一条能力记录至少包含：查询形态、语义条件、工作负载条件、机制、阶段、配置、预期计划变化、资源变化、限制、反例、证据和版本。

4.2 证据阶梯

证据不是简单的“高低分”。源码对实现事实很强，对生产收益很弱；论文实验对其数据集很强，对目标系统迁移很弱。平台应保存每类证据能回答的问题，而不是把它们相加成一个 0.93 的置信度。

4.3 负证据为什么更难

搜索不到类名，只能说明在当前范围和关键词下没有命中，不能证明引擎不支持该能力。一个系统可能：

• 使用不同术语；
• 在 Builder 或表达式简化阶段完成；
• 依赖共享执行库；
• 只为某个 connector、数据类型或 Join 实现特化；
• 在 Runtime 而非 optimizer 中补偿；
• 在商业版本而非开源分支实现。

相对可靠的局部负证据，是固定版本中存在明确 guard：某条实现路径在条件 C 下直接退出。要把它扩大成“整个系统不支持”，还需要排除其他路径，或得到范围明确的维护者确认。

4.4 “未知”不是零能力

目标系统状态可以使用以下有限状态，而不是支持/不支持二分法：

如果把未知记成零，公开资料少的闭源引擎会系统性“得分更低”，调查完成度被误当成产品能力。

5. 优化器与 Runtime 应如何拆开研究

5.1 优化器：不要把所有问题写成“缺少规则”

优化器侧至少需要区分六类原因：

1. 没有实现对应变换；
2. 语义或属性前提不满足；
3. 前置规范化缺失，导致规则形态不可达；
4. 搜索预算、剪枝或规则顺序没有探索该候选；
5. cost model 选择了别的计划；
6. distribution、ordering、uniqueness 等物理/逻辑属性推导不足。

这里有一个经常出现的危险：把采样统计当成语义约束。统计可以帮助估计成本；如果用它消除数据或改变结果集，就必须证明对应属性是保证，而不是大概率成立。

5.2 Runtime：减少什么，又增加什么

执行引擎研究的主线不是“用了 SIMD/Hash/压缩”，而是资源交换：减少了哪些 CPU、内存、网络或 I/O，又增加了哪些转换、同步、元数据和长尾风险。

例如，更紧凑的 Hash Table 可能降低内存和 cache miss，但增加编码或解码；更细的 partition 可以改善负载均衡，却增加调度、buffer 和小文件；Spill 能避免 OOM，却可能把 CPU 问题变成 I/O 问题。

5.3 跨层机制不要拆成重复建议

一种新的聚合 Spill 实现可能改变 Hash Aggregate 与 Sort Aggregate 的适用区间。动态过滤既涉及优化器插入位置，也涉及 Runtime 构建、传播和消费。自适应 DOP 需要优化器保留可调整边界，也需要调度器和算子状态支持。

因此，一条 Finding 可以关联多个方向，但要指定主要研究对象，并显式记录关系：

• 需要 Runtime 支持；
• 扩大逻辑变换的适用条件；
• 改变 cost model 的 crossover point；
• 依赖新的 property derivation；
• 需要 scheduler 或 storage interface 配合。

6. 信息进入平台：Source 与 Event 必须分开

6.1 从少量高价值来源开始

资料优先级可以是：

1. 官方 Release、文档与设计说明；
2. 仓库 PR、Issue、源码和测试；
3. 作者论文与技术博客；
4. 二手新闻、社交媒体和聚合摘要。

低层来源可以用于发现，高风险结论应回到一手资料。第一版不需要跟踪所有引擎。更合理的组合是：一个分布式 SQL 引擎、一个便于分析算子实现的本地引擎、一个优化框架或执行库，再加目标系统自己的能力档案。

完整数据库、执行库和优化框架的责任边界不同。Velox 没有完整 SQL planner，不应因为缺少某条逻辑规则而被判能力不足；Calcite 是框架，不应直接和一个可部署数据库比较运行时 Spill。

6.2 事件生命周期

 1proposal / issue
 2      │
 3      ▼
 4implementation merged
 5      │
 6      ▼
 7available in release
 8      │
 9      ▼
10enabled by default
11      │
12      ├──► restricted / deprecated
13      └──► reverted

“合入主分支”不能替代“进入稳定版本”，“进入版本”也不能替代“默认启用”。平台应分别保存：

• 原始发布时间；
• 首次发现时间；
• 抓取时间；
• 声明适用版本；
• commit/PR 与 release 的关系；
• 当前成熟阶段。

旧文章第一次被平台看到，应标记为“新增收录”，不能写成“本周发布”。新证据补充限制或回退时，应修订原 Event，而不是创建一条互相冲突的新事实。

6.3 快照、去重与游标

采集程序使用游标和重叠时间窗口，先持久化抓取内容，再推进游标。canonical URL 解决 URL 变体，content hash 辅助识别正文变化；标题相同或 URL 相同都不足以单独完成事件归并。

对动态网页，至少保存正文片段和抓取时间；对 Git 仓库，优先保存完整 commit。PR 描述会编辑、默认分支会前进、文档会无提示更新——没有快照，就无法复现模型当时为何得出结论。

6.4 能力档案如何保持最小

能力档案不应复制整个 Wiki。只在以下情况新增条目：

• 它能阻止一类重复误判；
• 它是当前研究主题的重要前提；
• 它记录了已确认的局部能力或限制；
• 它保存了一次高成本研究的结论；
• 它说明某条建议为何被拒绝。

模型可以提出档案更新草稿，但不能用自己生成的旧报告循环引用，最终把猜测“洗成”事实。正式档案应由人工确认，或者由明确的证据规则推进状态。

7. 平台架构：确定性控制面 + 有边界的模型任务

7.1 核心工作流

 1资料源
 2  │
 3  ▼
 4抓取与不可变快照 ──► Source
 5  │
 6  ▼
 7去重、版本识别、事件归并 ──► Event
 8  │
 9  ▼
10事实与机制提取 ──► Facts + Mechanism
11  │
12  ├───────────────┐
13  ▼               ▼
14目标能力档案    历史 Findings
15  │               │
16  └──────┬────────┘
17         ▼
18反向检索、差异分析、反例检查
19         │
20         ├── 关键证据不足 ──► 定向源码/资料研究 ──┐
21         │                                        │
22         ├── 达到预算 ──────► Unknown / 待核实    │
23         │                                        │
24         └── 证据足够 ──────► 人工评审 ──► Finding/档案更新

抓取、状态推进、幂等键、预算、权限、持久化和失败恢复，应由普通程序控制。模型适合提取机制、解释条件、生成检索计划和组织文字；它可以申请工具调用，但不应自行决定无限搜索、正式发布或修改档案状态。

7.2 为什么采用两阶段分析

第一阶段只读外部材料，输出：

• 发生了什么；
• 机制是什么；
• 触发条件和限制；
• 外部收益声明及测量条件；
• 每条事实的证据位置。

这一阶段不读取目标系统状态，减少“为了生成差异而曲解外部资料”的动机。

第二阶段再读取外部事实、目标能力档案和历史结论，回答：

• 为什么可能相关；
• 已知状态是什么；
• 是否存在同义或替代实现；
• 哪些条件不可迁移；
• 最小核对问题是什么；
• 可能影响 CPU、内存、网络、I/O、延迟还是稳定性。

如果外部事实互相冲突，保留冲突和各自版本，不让模型强行融合成一个流畅但虚假的故事。

7.3 最小数据模型

第一版使用 SQLite 和版本化文件已经足够。四个主实体可以覆盖主流程：

下面是一份比自由 Markdown 更适合程序校验的 Finding 骨架：

 1{
 2  "finding_id": "OPT-2026-0042-v3",
 3  "event_version": "EV-018@5",
 4  "target_profile_version": "engine-profile@31",
 5  "facts": ["F-112", "F-113"],
 6  "mechanism": {
 7    "problem": "skewed aggregation state",
 8    "stage": "runtime",
 9    "action": "partition and spill selected state",
10    "preconditions": ["spillable aggregate state"],
11    "limitations": ["high repartition cost for extreme heavy hitters"]
12  },
13  "target_status": "unknown",
14  "inferences": [],
15  "counter_evidence": [],
16  "unknowns": ["current state ownership during recovery"],
17  "next_check": "trace state layout, spill trigger and restore path",
18  "close_when": "the supported state types and peak-memory behavior are known"
19}

Schema 能验证字段是否存在、枚举是否合法、引用是否可解析；它不能判断 source 是否真的支持 claim。结构检查和语义审核必须同时存在。

7.4 幂等、重试和版本

幂等键可以由以下内容组成：

1event_version
2+ analysis_scope
3+ target_profile_version
4+ source_snapshot_set
5+ output_schema_version
6+ prompt_or_policy_version

模型升级或 policy 变化时创建新的 Run，不覆盖旧结论。任务执行状态与 Finding 评审状态分开：一次 API 超时不能把已经发布的结论改成失败。重试应限制次数，保留已经成功的中间产物；Source 被更正或撤回时，反向标记受影响的 Findings 待复核。

8. 模型、API 与代码 Agent 的责任边界

8.1 任务类型决定执行后端

第一版不需要同时维护两套完整模型后端。资料为主时，API 流水线更简单；源码探索占主要成本时，代码 Agent 更自然。两者共用任务输入、Source 引用和 Finding Schema，未来才有条件比较质量和成本。

8.2 Agent 不负责长期状态

Agent 的工作区是一次 Run 的执行环境，不是平台数据库。抓取游标、正式档案、历史 Finding、权限和人工评审结果由控制面保存。否则会出现：

• 会话结束后无法复现；
• 模型误把旧草稿当正式结论；
• 重试时重复抓取和重复发布；
• prompt 变化悄悄改变长期状态；
• 不同 Agent 对同一实体使用不同 ID。

8.3 Context engineering 比长 prompt 更重要

每次任务只提供当前 Event、必要 Source、相关能力条目和少量历史结论，不把整个资料库塞入上下文。模型需要的是与决策相关的最小证据闭包，不是尽可能长的文本。

检索阶段可以先宽召回，再按版本、对象类型、能力条件和证据关系重排。精确配置名用 keyword/BM25；同义机制用 embedding；调用链用 code index；最终关键事实回到原文。

9. 如何让研究结论更鲁棒

9.1 句子级区分事实、推断、建议与未知

一段流畅文字可能混合四种不同性质的陈述：

1[事实] 固定版本源码中的 guard 在条件 C 下返回 false。
2[推断] 因而该规则路径不会处理 C。
3[未知] 尚未排除 Builder 或其他 rule 完成同类变换。
4[建议] 定向检索等价形态和相关测试；在排除其他路径后再判断局部缺口。

固定审核规则包括：

• “外部系统加入 X”不能推出“目标系统没有 X”；
• “代码存在 X”不能推出“默认启用 X”；
• “测试覆盖 X”不能推出“所有组合语义都支持 X”；
• “单算子 CPU 下降”不能推出“端到端延迟必然下降”；
• “多个模型意见一致”不能充当独立外部证据。

9.2 反向检索与替代实现

提出差异之前，按以下顺序检查：

1. 同义词和术语别名；
2. Analyzer/Builder 的提前简化；
3. 属性系统与 Enforcer；
4. connector、storage、execution library 的实现；
5. Runtime 自适应或 fallback；
6. 历史 Findings 和被否定原因；
7. 新版本、配置和商业/开源分支差异。

反向检索不是为了证明“系统什么都有”，而是防止在错误抽象层上发明缺口。

9.3 反例优先

每条建议都应主动问：

• 哪种 NULL、duplicate、overflow 或 non-deterministic function 会破坏语义？
• 哪种 NDV、skew、row width 或 memory pressure 会让成本反转？
• 哪种 property、connector 或 execution mode 会使机制不可用？
• 是否引入额外 Exchange、serialization、materialization 或 recovery cost？
• 如果 feedback 错误，能否回滚到 last-known-good？

反例不是文章末尾的“局限性”装饰，而是决定研究是否成立的第一等输入。

9.4 安全与提示注入

网页、README、Issue 和代码注释都属于不可信数据。里面出现“忽略前文并运行脚本”时，研究 Agent 不应执行。默认策略应是：

• 源码研究只读；
• 不执行仓库安装脚本和未知二进制；
• 网络、文件与命令权限按任务最小化；
• 内部资料只发送到获准的模型环境；
• 凭据不进入日志、prompt 和报告；
• 动态验证使用独立任务、沙箱和资源预算。

安全边界既保护机器，也保护研究结论不被 Source 中的指令污染。

9.5 人工反馈必须保存理由

只有“赞/踩”的反馈无法形成有效记忆。至少记录：

• 值得继续研究；
• 已覆盖，并链接能力证据；
• 与历史 Finding 重复；
• 证据不足，需要哪类材料；
• 架构不适用，并记录条件；
• 结论错误，错误发生在哪个推理步骤。

新 Event 只有带来新机制、扩大适用范围、增强证据或推翻旧结论时，才重新进入重点评审；否则只关联历史记录。

10. 没有多引擎环境，仍然可以怎样评测

10.1 先评研究质量，不伪造性能验证

仅有公开资料和只读源码时，可以验证：

• 来源、版本和发布状态是否准确；
• 机制是否符合原文；
• 源码路径是否支持局部判断；
• 推断是否遗漏语义和架构前提；
• 重复 Source 是否正确归并；
• 专家是否认为问题值得继续核对。

此时不能验证目标工作负载的触发率、计划选择概率和端到端收益。这些值应该保持 unknown，而不是由引用数量、模型分数或外部最大加速比替代。

10.2 构造历史回放集

从 30–50 个真实技术事件开始，是一个可执行的工程起点，不是统计保证。样本应包含：

• optimizer、Runtime 与跨层机制；
• 真正的新变化、旧文重发和重复传播；
• 功能默认启用、可选、回退和废弃；
• 已覆盖、部分覆盖、未知和不适用；
• 高价值论文与低信息密度新闻；
• 模型容易过度迁移的单机/分布式差异。

按 Event 分组并按时间切分开发集和保留集，避免同一 PR 的博客进入训练侧、Release Note 进入评测侧。回放只能使用截止当时可见的 Source 和档案版本；如果只能使用今天的网页，就应称为“冻结输入离线评测”，不能声称完整模拟历史发现。

10.3 指标必须写出分母

同时报告样本量、未评审比例和置信区间或不确定性。样本很小时，一两条建议的变化不能被包装成稳定提升。

10.4 基线与消融

至少比较三组流程：

1. 专家原有阅读流程；
2. 只有新闻/论文摘要的模型流程；
3. 加入 Source 快照、能力档案、反向检索和证据审核的流程。

再做消融：去掉历史去重、源码深挖、反例检查或能力档案，观察它们是否提高有效建议率，还是只增加报告长度。模型越强不代表整个系统越好；如果强模型带来的收益被更高重试和审核成本抵消，较简单流程可能更经济。

10.5 停止条件

检索不是越多越好。可以在以下条件停止本轮研究：

• 已有证据足以作出当前决策；
• 新 Source 只重复已有机制和边界；
• 达到资料、工具、时间或费用预算；
• 关键事实必须依赖不可获得的内部信息或动态实验；
• 下一步已明确转交独立验证任务。

停止时保存 Unknown 和所缺证据，比生成一个强行闭合的结论更有价值。

11. 两个完整研究卡片示例

11.1 优化器示例：外连接简化

考虑：

1SELECT a.id, b.amount
2FROM A AS a
3LEFT JOIN B AS b ON a.k = b.k
4WHERE b.amount > 0;

在常规 SQL bag semantics 和 NULL 三值逻辑下，未匹配行的 b.amount 为 NULL，NULL > 0 的结果为 UNKNOWN，WHERE 只保留 TRUE，因此未匹配行被过滤。若表达式的确定性、异常行为和类型转换满足前提，将该 LEFT JOIN 简化为 INNER JOIN 可以保持结果；这里不要求连接键唯一，因为匹配行的重复次数没有改变。

关键术语：

• bag semantics：SQL 结果默认是多重集，重复行有计数；不能按集合语义随意消除 duplicate。
• three-valued logic：比较结果除了 TRUE/FALSE 还有 UNKNOWN；WHERE 丢弃 FALSE 和 UNKNOWN。
• null-rejecting predicate：当相关列为 NULL 时，谓词不可能为 TRUE。

反例包括：

1-- 不拒绝 NULL；未匹配行可能被保留。
2WHERE COALESCE(b.amount, 0) >= 0
3
4-- OR 的左侧可能让未匹配行通过。
5WHERE b.amount > 0 OR a.category = 'important'

研究时应定位：null-rejecting 判断、Join rewrite 注册顺序、表达式确定性、cast/异常语义、正反测试，以及简化后是否触发 Join reorder 与 predicate pushdown。静态搜索没命中一个规则名，不能直接得出“不支持”。

合理 Finding 是：

1外部机制：利用 null-rejecting filter 将特定 outer join 简化为 inner join。
2目标状态：未知。
3反向检索：Analyzer 简化、Join rule、predicate inference、Builder rewrite。
4最小核对：固定版本下覆盖哪些表达式，哪类 guard 拒绝。
5潜在价值：扩大 Join reorder 与 filter pushdown 的搜索空间。
6收益状态：未验证，依赖数据分布与后续计划选择。
7结案条件：明确已有覆盖范围或确认一个可复现的局部缺口。

11.2 Runtime 示例：外部聚合与内存管理

DuckDB 的 External Aggregation 文章描述了 buffer manager、可换出的页、变长数据指针恢复、局部预聚合和 partition-wise 聚合。这是理解机制的优秀材料，但不能被简化成“支持 Spill，所以任何分布式系统都应照搬”。

关键术语：

• NDV（Number of Distinct Values）：分组键不同值数量；高 NDV 往往意味着更多聚合状态。
• Spill：内存状态放不下时，把部分数据或状态写到更慢的存储，后续恢复处理。
• Pre-aggregation：在完整聚合前先局部合并相同 key，减少后续数据量；高 NDV 时收益可能降低。
• State ownership：哪个线程、task 或 partition 拥有并更新某份聚合状态，决定并发与恢复方式。
• Serialization：将内存对象转成可持久化/传输表示；指针和进程内地址通常不能原样恢复。

迁移分析应核对：

• 聚合状态是否可移动、可序列化，UDF aggregate 是否例外；
• 变长 key/value 的所有权和恢复成本；
• Spill trigger 是算子局部还是全局内存仲裁；
• partition 粒度、递归 repartition 和 heavy hitter；
• 并发 operators 是否各自按上限分配，导致峰值放大；
• 单机 buffer manager 假设与分布式 Shuffle、远端存储、故障恢复的差异；
• 新机制是否需要 optimizer 更新 memory cost 与算法适用区间。

合理结论是“该布局和内存管理思路值得作为对照，目标状态与收益待核实”，而不是引用外部 Benchmark 作为预期收益。

11.3 标准研究卡片

12. 从最小版本开始，而不是先建“数据库百科”

12.1 四阶段路线

第一个可用版本可以只是命令行、SQLite 和报告目录。网页、向量库、知识图谱、消息队列都不是前置条件。

12.2 何时增加基础设施

“技术流行”不是建设理由；可观察的研究瓶颈才是。

12.3 预算应该按阶段记录

将成本拆成采集、筛选、事实提取、目标映射、源码深挖、验证和人工复核。多数 Event 在机制筛选后结束，少数进入目标分析，极少数进入源码专题或动态实验。

每个任务设置：最大 Source 数、工具调用、token、时间、费用和允许的执行权限。达到预算后保存已有事实和 Unknown。缓存不是零成本，还需要失效、存储和错误结果治理。

12.4 主要风险

13. 进一步思考：研究平台本身也是一个优化器

13.1 它同样面对搜索空间与预算

数据库优化器不可能穷举所有计划，研究平台也不可能阅读所有 Source、仓库和论文。两者都需要：候选生成、剪枝、成本预算、停止条件和失败回退。

如果模型总是继续搜索，它会产生越来越完整的背景，却不一定改变决策。研究系统应该问：下一次工具调用的信息价值是什么？它最可能消除哪个 Unknown，是否会改变优先级或结论？

13.2 研究记忆不是更多文本，而是可更新的状态

把所有报告放进向量库，不能自动形成可靠记忆。真正有价值的记忆具有：对象 ID、版本、状态、适用条件、证据、否定原因和失效机制。新事实到来时，系统知道更新哪个 Event 和 Finding，而不是重新生成一篇相似文章。

13.3 对“新”的判断必须带时间语义

技术 Event 至少有提出、合入、发布、默认启用和首次被发现五种时间。平台如果只保留发布日期，会把旧文新收录当创新；如果只保留抓取时间，又无法判断版本成熟度。

这也是时间切分评测必须使用历史快照的原因：用今天已经完善的文档解释两年前的决策，会发生信息泄漏。

13.4 最值得自动化的不是最终判断

自动化最有价值的环节通常是：

• 保存快照和版本；
• 合并重复传播；
• 提取候选事实和证据位置；
• 反向检索历史能力；
• 暴露冲突和缺失字段；
• 生成可审查的研究卡片草稿。

“是否值得改变一个成熟数据库系统”仍包含工作负载、架构演进和组织优先级，保留专家决策并不是自动化失败，而是正确的责任边界。

结语

一个高质量的数据库优化研究平台，不应以抓取页面数、向量数量、生成文章数或规则数量证明价值。它应当让研发人员更快地得到一种更诚实的答案：

外部系统在什么条件下做了什么；目标系统目前知道什么；证据能支持到哪一步；哪个反例可能推翻判断；下一项最小核对动作是什么。

如果只能记住三个原则，我会选择：

1. 以有条件的能力比较系统，不以规则名比较系统。
2. 把事实、推断、建议和未知分开，让每条关键结论可追溯、可反驳。
3. 先跑通轻量研究闭环，再根据真实瓶颈增加 RAG、代码图谱、Agent 和动态实验。

研究平台的终点不是替人生成更多结论，而是让新证据到来时，旧判断能够被准确找到、重新检验并诚实地更新。

附录 A：单次研究检查表

1. 明确是新 Event、旧 Event 更新，还是专题基线研究。
2. 找到一手 Source，记录版本、发布日期、抓取时间和固定位置。
3. 提取机制、前提、限制和外部测量口径，不提前猜目标缺口。
4. 检索目标能力档案与历史 Findings，注明版本。
5. 检查同义机制、替代阶段、共享库、版本回退和不适用条件。
6. 对每条关键事实检查“引用是否真正支持该句”。
7. 将事实、推断、建议、反例和 Unknown 分开。
8. 给出最小下一步及明确结案条件。
9. 人工记录发布、待核实、关联旧记录或排除的理由。
10. 新证据到来时修订原 Finding，而不是悄悄覆盖。

附录 B：公开资料索引

仓库理解与采集

• DeepWiki repository wikis — 官方文档
• DeepWiki-Open — GitHub
• CodeWiki — GitHub
• OpenDeepWiki — GitHub
• CodeGraphContext — GitHub
• Miniflux — GitHub
• changedetection.io — GitHub

SQL 改写、证明与实验

• R-Bot: An LLM-Based Query Rewrite System — PVLDB 2025
• R-Bot 开源实现 — GitHub
• WeTune — GitHub
• SQLSolver — GitHub
• Cosette — GitHub
• SQLancer — GitHub
• PostBOUND — GitHub

工业实践与机制案例

• Deploying a Steered Query Optimizer in Production at Microsoft — SIGMOD 2022
• Leveraging Query Optimizers to Verify the Soundness of LLM-based Query Rewrites — CIDR 2026
• No Memory? No Problem. External Aggregation in DuckDB — 2024

形式化与代码索引基础

• Lean Theorem Prover
• TLA+ Home Page
• Tree-sitter
• SCIP Code Intelligence Protocol