-46% 还是 -2%?规则改写器只在自己家有效
在 TPC-H 10GB 上,一个学界 SOTA 的规则改写器把平均执行时间从 69.84s 砍到 37.57s,-46%。换到 DSB 10GB,同一个改写器把 32.62s 砍到 31.93s——只有 -2.1%。差距不在 query 难度,而在 benchmark 是不是它的训练集。“规则系统稳定可靠"很多时候是基准过拟合,不是工程事实。
Llm
解剖一份让 LLM 改物理计划的 120 行 prompt
DBPlanBench 让 GPT-5 在 TPC-H SF10 上把 DataFusion 几何平均加速 4.78×。我对着它的 sql_optimization_prompts.py 数了一遍——120 行,方法论 30 行,剩下 90 行全在给 LLM 立合同。这个比例本身就是这条路线最值得抄走的东西。
只让 LLM 改 SQL,几乎什么都不会发生
在 TPC-H 10GB 上,直接让 GPT-4o 改写 SQL,平均执行时间从 78.81s 降到 74.92s——几乎等于没改。换一个开源 14B 模型,喂 plan、加 reward、训一遍,同样的工作量降到 29.67s。LLM 在 SQL rewrite 上能不能工作,不取决于 LLM 多强,取决于你愿不愿意给它真正能改 SQL 的信号。
LLM 做 Join Order：从 Databricks 的实验,看 Apache Spark 视角下的三层落地阶梯
Databricks 与 UPenn 把 LLM agent 当成离线 join-order 调优师,在 JOB 113 条查询上拿到 P90 -41% / 几何均值 1.288× 的提速,甚至超过"完美基数估计"。从 Apache Spark 一线视角看,这件事说明了什么、又没说明什么。