-46% 还是 -2%?规则改写器只在自己家有效
在 TPC-H 10GB 上,一个学界 SOTA 的规则改写器把平均执行时间从 69.84s 砍到 37.57s,-46%。换到 DSB 10GB,同一个改写器把 32.62s 砍到 31.93s——只有 -2.1%。差距不在 query 难度,而在 benchmark 是不是它的训练集。“规则系统稳定可靠"很多时候是基准过拟合,不是工程事实。
博客
解剖一份让 LLM 改物理计划的 120 行 prompt
DBPlanBench 让 GPT-5 在 TPC-H SF10 上把 DataFusion 几何平均加速 4.78×。我对着它的 sql_optimization_prompts.py 数了一遍——120 行,方法论 30 行,剩下 90 行全在给 LLM 立合同。这个比例本身就是这条路线最值得抄走的东西。
翻转分支找性能 bug：ETH 的 BFA 方法，以及它对 Spark 意味着什么
ETH 的一篇新论文用「把优化分支翻一下，看谁更快」这一招，在 PostgreSQL、MySQL、CockroachDB、MariaDB 上挖出 21 个此前未知的性能 bug。方法概念简单，Spark 这边的落地接口意外地齐整 —— spark.sql.optimizer.excludedRules 几乎就是现成的翻转开关。
只让 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 一线视角看,这件事说明了什么、又没说明什么。
深入 Spark SQL Metrics（第六部分）：实战——TPC-DS q99 的 Gluten 指标全解读
SQL Metrics 系列第六部分。以 TPC-DS q99（SF10000，Gluten/Velox）为例，逐算子解读每个指标，展示如何从指标中读懂查询执行的全貌。
深入 Spark SQL Metrics（第五部分）：Gluten 指标收集的内部机制
SQL Metrics 系列第五部分。Gluten 如何将 Substrait 计划节点映射到 Velox 算子、跨管道聚合指标、遍历 MetricsUpdaterTree，以及聚合子阶段和 Shuffle 指标的内部机制。
深入 Spark SQL Metrics（第二部分）：内部机制与 AQE 的运行时决策
SQL Metrics 三部曲的第二部分。指标如何从任务流向Driver，以及自适应查询执行（AQE）如何利用 Shuffle 统计信息在运行时重写查询计划。
深入 Spark SQL Metrics（第三部分）：扩展 API、UI 渲染与 REST API
SQL Metrics 三部曲的第三部分。如何通过 DataSource V2 API 扩展自定义指标、UI 如何渲染指标、以及如何通过 REST API 编程查询指标。
深入 Spark SQL Metrics（第四部分）：Gluten 如何扩展指标系统
SQL Metrics 系列的第四部分。Apache Gluten 如何将 Velox/ClickHouse 原生指标桥接回 Spark SQL Metrics 框架，添加了 60+ 个原生 Spark 没有的指标。