基数估计是优化器的心脏。北大和字节团队拿 Llama-3 8B 微调后做 CardEst,在 IMDB、STATS 等负载上 Q-error 99 分位最高比最佳 baseline(PRICE)降 74.1%——精度是真赢了。但端到端一测就翻车:在 JOB-light、ErgastF1 上,LLM 更准的计划反被它自己的推理延迟拖累,总时间比最强 baseline PRICE 还长。真正的工程贡献不是模型,是那个用优化器成本模型当看门人的门控:只对高成本子查询调 LLM,其余交给老办法。
微软团队拿真实企业客户负载评测 LLM 索引调优:在 Real-R 的 query 22 上,SOTA 商用调优器 DTA 推荐的索引导致近 10× 退化,同一条 query,GPT-5 把执行时间从 10 秒压到 4 秒。LLM 赢的地方,恰恰是 what-if 成本模型估错的地方。但这份直觉高方差、缝不进现有架构、也无法廉价验证——它现在不是 DTA 的替代品,是它视野之外的候选索引的来源。
在 TPC-H 10GB 上,一个学界 SOTA 的规则改写器把平均执行时间从 69.84s 砍到 37.57s,-46%。换到 DSB 10GB,同一个改写器把 32.62s 砍到 31.93s——只有 -2.1%。差距不在 query 难度,而在 benchmark 是不是它的训练集。“规则系统稳定可靠"很多时候是基准过拟合,不是工程事实。
DBPlanBench 让 GPT-5 在 TPC-H SF10 上把 DataFusion 几何平均加速 4.78×。我对着它的 sql_optimization_prompts.py 数了一遍——120 行,方法论 30 行,剩下 90 行全在给 LLM 立合同。这个比例本身就是这条路线最值得抄走的东西。
ETH 的一篇新论文用「把优化分支翻一下，看谁更快」这一招，在 PostgreSQL、MySQL、CockroachDB、MariaDB 上挖出 21 个此前未知的性能 bug。方法概念简单，Spark 这边的落地接口意外地齐整 —— spark.sql.optimizer.excludedRules 几乎就是现成的翻转开关。
在 TPC-H 10GB 上,直接让 GPT-4o 改写 SQL,平均执行时间从 78.81s 降到 74.92s——几乎等于没改。换一个开源 14B 模型,喂 plan、加 reward、训一遍,同样的工作量降到 29.67s。LLM 在 SQL rewrite 上能不能工作,不取决于 LLM 多强,取决于你愿不愿意给它真正能改 SQL 的信号。
Databricks 与 UPenn 把 LLM agent 当成离线 join-order 调优师,在 JOB 113 条查询上拿到 P90 -41% / 几何均值 1.288× 的提速,甚至超过"完美基数估计"。从 Apache Spark 一线视角看,这件事说明了什么、又没说明什么。