技术深度解析
将LLM集成到查询优化中代表了一次根本性的架构转变。传统的基于成本的优化器遵循一个确定性流程：解析SQL，生成一组逻辑上等价的查询计划，使用基于基数估计、I/O和CPU成本的模型为每个计划分配成本，然后选择成本最低的计划。该模型的弱点在于其依赖准确的统计信息，且无法处理未见过的查询模式或复杂的相关性。
基于LLM的优化器通过以下几种关键方式颠覆了这一流程：
1. 基于学习的成本建模： 与固定公式不同，LLM可以被训练来预测候选计划的实际执行时间或资源消耗。训练数据由查询计划与其实际执行指标（延迟、CPU周期、I/O）配对组成。像 PostgreSQL的pg_hint_plan 扩展或微软的 Query Embeddings 研究等项目展示了如何将计划特征向量化以供模型使用。
2. 利用启发式智能进行计划空间剪枝： 复杂查询的可能执行计划空间极其庞大。LLM可以充当智能剪枝器，利用其对语义上下文的理解（例如，“这是一个时间序列汇总查询”）来立即丢弃不合理的计划形态，并将搜索集中在有希望的区域。这类似于国际象棋引擎使用启发式方法来避免评估明显糟糕的走法。
3. 跨优化洞察： LLM可以关联不同查询之间以及随时间推移的优化决策。例如，它可能观察到创建某个复合索引，虽然前期成本较高，却能显著改善一整类频繁查询的性能——这是专注于单个查询的传统CBO会忽略的整体性洞察。
该领域一个开创性的开源项目是 “Bao”（最初来自威斯康星大学麦迪逊分校，现在有社区分支）。Bao使用强化学习，根据观察到的性能来学习应对PostgreSQL数据库应用哪些查询提示。虽然严格来说它不是一个LLM，但其架构——一个与传统优化器并存并覆盖其决策的学习模型——是LLM集成的蓝图。
近期的基准测试虽然仍处于早期阶段，但已显示出有希望的结果。在连接顺序基准测试（JOB）的受控测试中，早期学习型优化器原型已能找出比PostgreSQL原生优化器为最复杂查询选择的执行计划快2-3倍的执行计划。
| 优化方法 | 核心机制 | 优势 | 劣势 |
|---|---|---|---|
| 传统基于成本的优化器 | 静态成本公式，直方图统计 | 久经考验、稳定、可预测 | 对关联数据、复杂连接处理不佳；需要完美的统计信息 |
| 强化学习（例如，Bao） | 学习计划提示的奖励（延迟） | 适应特定工作负载 | 需要大量训练；难以适应突然变化 |
| 基于LLM的优化器 | 对查询/数据的语义理解，通过嵌入向量预测成本 | 可泛化，能推理未见模式，具有整体视图 | 推理延迟高；决策是“黑盒”；内存占用大 |
数据要点： 上表演示了从僵化的、基于规则的系统向自适应的、基于学习的系统的演进。LLM在泛化能力和整体推理方面潜力最大，但也带来了延迟和可解释性方面的新挑战，这些必须在生产使用中解决。
主要参与者与案例研究
构建AI优化数据库的竞赛正在初创公司和行业巨头之间展开，各方策略各异。
注入AI的行业巨头：
* 微软（Azure SQL Database, Cosmos DB）： 微软正深度整合其Azure OpenAI能力。虽然未公开详述完整的基于LLM的优化器，但其 “Azure SQL Database Automatic Tuning” 使用机器学习来检测和修复性能回归，应用索引和计划强制建议。合乎逻辑的下一步是使用像GPT-4-Turbo这样的模型，基于对性能问题的自然语言描述来生成这些建议。
* 谷歌云（AlloyDB, Spanner）： 谷歌利用其基础性AI研究。AlloyDB的智能缓存和列式引擎已使用ML进行预测。谷歌研究院在 “Learned Cardinality Estimation” 方面的工作直接针对CBO的一个核心弱点。集成像PaLM 2这样的模型来监督整个优化过程，是一个合理的路线图。
* 甲骨文（Autonomous Database）： 甲骨文的旗舰产品被定位为“自治”。其机器学习模型持续监控工作负载和配置，执行索引管理和SQL计划调优。纳入大型基础模型以理解业务上下文（例如，“优先处理季度末报告查询”）将是这一愿景的自然演进。
AI原生初创公司：