一句话定义：学习型查询优化器（Learned Query Optimizer）是用机器学习模型，部分或全部取代数据库里"按公式估代价、挑最便宜计划"的老逻辑，让它从历史执行数据中学会"这条 SQL 该怎么跑最快"。
为什么需要它：SQL 只说"要什么"，不说"怎么拿"。同一条查询，先扫小表再连接，还是先连接再过滤，耗时能差几个数量级。传统优化器靠代价模型（cost model）给每种方案估个价：要读多少行、每行多贵，然后选总价最低的。问题在于"估算"经常离谱——统计信息过期、列与列相关、数据倾斜，基数估错 10 倍，代价可能错上百倍。
打个比方：经典优化器像只看地图和限速牌估时间的老司机；学习型优化器像手里握着几百万条真实行车记录，直接说"这个点走这条路，历史平均 12 分钟"。
训练数据怎么造（最难的一环）：
1. 线上查询日志配真实执行耗时——最贴近现实，但只覆盖"走过的路"；
2. 主动采样：随机生成或改写 SQL 并真的执行一遍，把实测耗时当标签——覆盖广，但很贵；
3. 让经典优化器产出多个候选计划，学一个排序模型（learning to rank）挑最好的。
特征上，通常把执行计划树编码成序列或图，输入表基数、谓词选择率、连接结构等，输出预测耗时或"哪个计划更优"。
和邻近概念的分界：
- 学习型基数估计（learned cardinality estimation）：只替换"估行数"这一步，常作为经典优化器的插件；
- 学习型计划选择：直接决定用哪个计划，可以端到端生成；
- 自动索引 / 自动调参：改的是数据库的长期配置，不是这一次查询的路线。
| 经典代价优化器 | 学习型优化器 | |
|---|---|---|
| 依据 | 人工写的代价公式 + 统计信息 | 从执行数据学到的预测模型 |
| 冷启动 | 立刻可用 | 需要数据和训练 |
| 主要风险 | 基数估计误差被层层放大 | 遇到没见过的 schema 或分布就失灵 |
| 可解释性 | 能说清为什么选它 | 多为黑盒 |
| 维护 | 更新统计、调参数 | 重训、监控漂移、备好回退 |
"4B 模型生成的计划比 Postgres 快 81%"怎么看：这类结果一般指在某个固定基准上，用几十亿参数的小模型直接生成执行计划，平均耗时优于 PostgreSQL 默认计划。它说明"小模型 + 好数据"在结构化决策上确实有戏，但有三点要记住：提升多是平均值，尾延迟未必更好；基准的 schema 和数据分布固定，换到自家库未必复现；标签要靠真跑查询换，成本不低。具体数字以原论文和代码仓库为准。
落地边界：生产上很少"一把换掉"优化器，更常见的是旁路——用模型挑候选、给建议，或只接管少数已知易错的查询类型，同时保留经典优化器兜底和一键回退。
对你的意义：后端和 DBA 近期能落地的，多半是慢查询诊断加改写、索引建议；AI 从业者可以把它当成"结构化决策 + 昂贵反馈"的典型题，思路和排序模型、强化学习相通。普通用户感觉不到它的存在，但报表可能因此快几秒——前提是监控和回退都在位。