查询调整器是关系数据库最精巧、也最脆弱的子程序。四十多年来信息 + 动态规划作为骨架，把一条 SQL 翻译成一棵执行计划树。按理说，它大部分时候工作得不错，但在 join 条件相关、数据倾斜、或者查询模板变化剧烈的工作负载下代价估计的偏差会被选择性乘积放大到几个数量级。最终让执行器跑在一个完全不合理的计划上。

一、CBO 基础：为什么 learned QO 有机会

把话题拉回最基本的地方。一条 SQL 在 PostgreSQL 里从字节流变成结果集的途中经过五个阶段：

parse tree ──▶ query tree ──▶ logical plan ──▶ physical plan ──▶ executor
语法检查 语义
关系代数 具体算子选择 迭代执行

CBO 只活在“logical → physical”这一步。它的职责就是的观比如点是，给定一棵逻辑关系代数树，决定每个 join 用什么算法。还有每个扫描用什么方式，再有还有多表 join 的顺序。怎么说呢，

这听起来狭窄。但这一步的代价分布极不均匀——两个计划可能差几万倍。其实，整个数据库领域过去四十年花在 CBO 上的研究论文可能比文件程序还多。就是因为这一步做好了其它所有事才值得做。

System R 的遗产

• 把计划空间限制为 left-deep tree这样 DP 的子问题只依赖 join 子集而不依赖子集形状。
• 用一个 cost function 把 CPU、I/O、网络折算成一个标量，作为 DP 的比较键。按理说，
• 用 selectivity 估计每个谓词和 join 的选择性。 进而估计中间结果基数，

这三条在今天几乎所有主流调整器里都能找到直接对应。至于问题在于，cost function 是一组写死的系数。selectivity 依赖直方图和独立性假设。两者都会在实际工作负载上失效。

代价估计为什么会偏差几个数量级

User Pain Point: 对于 OLTP 场景。即使单表谓词 selectivity 在 2x 内，也会因为两张表 join 开始出现十倍误差；四张表以上常常偏差千到万倍，这直接导致执行时间灾难性增长。

Papers such as Leis et al.'s “How Good Are Query Optimizers,Really?” found:

• 单表谓词 selectivity 通常在 2x 内；老实说，
• 两张表 join 的 cardinality 开始出现 10x 级误差；
• 四张表以上 join 常常偏差从100x到10000x。

This exponential blow-up is a direct consequence of independence assumptions. Once cardinalities are wrong,cost comparison becomes meaningless;DP picks a plan that is “optimal for a wildly inaccurate estimate.” This leaves room for learned QO: if a model can provide 娱乐ter cardinality estimates or directly rank plans more accurately,it can bypass CBO’s structural shortcomings.

二、Neo：端到端学一个调整器

User Pain Point:- Neo’s end-to-end approach sounds attractive but introduces a heavy cold-start cost and sensitivity to schema changes.

A 架构 Overview

• Plan encoder: Tree Convolutional Neural Network encodes operators and table/column one-hot vectors plus child embeddings.
• Value network: Given a plan embedding。predicts expected latency.
• Plan search: Best-first search explores plan space guided by value network.

The training pipeline starts with expert bootstrapping using PostgreSQL’s plans + real execution times and n continues online by executing its own chosen plans.

A 真正的贡献与局限

• COLD START EXPENSIVE: Bootstrapping needs thousands of labeled queries—unfriendly for production workloads.
• SCHMA CHANGE SENSITIVE: A new table or column changes encoder input dimensions—model often needs retraining.
• CATASTROPHIC REGRESSION: Occasionally outputs plans that are dozens of times slower than CBO—unacceptable in OLTP settings.

The last two problems directly motivated Bao.

三、Bao：不替换 CBO，只挑 hint

Bao’s stance: “CBO is mostly correct;learned components only need to fix its mistakes.” It reframes learning as a contextual bandit problem over a predefined hint set.

• {}这方面，let PostgreSQL decide freely;
• {no nested loop}: disable nested-loop joins;
• {no merge join,no index scan}: only hash joins + seq scans;