Andy Pavlo 如何用 OtterTune、自動調優與 optd 推進 AI 資料庫？

資料庫效能問題很少只靠一個參數解決。查詢計畫、索引、記憶體、並行控制、硬體與工作負載會彼此影響，雲端環境還加入成本與彈性變數。Andy Pavlo 的研究價值，在於把這個長期依賴資深 DBA 經驗的領域轉成可觀測、可學習、可驗證的系統問題。從 Peloton、OtterTune、自駕資料庫到 optd，他探索的不是用 AI 替人調一個 knob，而是資料庫能否理解自身狀態並在風險邊界內持續改善。

先說清楚現況：OtterTune 已不是仍在營運的新創故事

許多舊介紹仍稱 Pavlo 為 OtterTune 執行長，但他的CMU 個人官方頁在二〇二六年更新時已明確寫出，他曾是 OtterTune 共同創辦人兼執行長，而該新創後來結束。這個事實不會抹去研究價值，反而能讓我們把技術成果與公司結果分開評估：自動調優是一個重要方向，某次商業化沒有長期存續，兩者可以同時成立。

相較之下，CMU Computer Science Department 人物頁仍保留較早的 OtterTune 職務描述。面對這種官方頁面更新不同步，可靠內容應採較新、由本人維護的頁面作現況依據，再把舊頁用於學術職稱與研究背景。這也是資料治理本身的縮影：來源權威不代表每個欄位都同樣新鮮。

他的核心問題：DBMS 能不能自行選擇、部署並學習調整

Pavlo 對 self-driving database 有比行銷口號更嚴格的定義。他在官方文章〈What is a Self-Driving Database Management System?〉中提出，完整自駕系統必須能自行決定採取哪些改善動作、何時部署，並從結果學習，而且不依賴人類逐次介入。只有推薦參數、最後仍由 DBA 手動判斷，不足以稱為 fully self-driving。

這三個條件把問題從預測模型拉回控制系統。推薦可能準確，部署卻會鎖表；某次調整提升吞吐，下一個負載區間卻可能退化；模型若不知道自己剛改過什麼，就無法把結果歸因。真正自治需要狀態觀測、動作空間、目標函數、風險約束、回滾與持續回饋，而不是單次離線訓練。

Peloton 與 NoisePage：先建立能被控制的研究載體

要研究自治 DBMS，只在外部觀察黑箱並不夠。Pavlo 團隊先用 Peloton 探索記憶體交易、即時分析與自動化元件，之後重建為 NoisePage，讓研究者能控制 optimizer、storage、execution 與 telemetry。完整系統很昂貴，但它能揭露個別模型在真實資料路徑上的互動成本。

他的個人頁現在已把 Peloton 與 NoisePage 列為結束專案，不能再描述成現行主力。這段歷史的意義，是研究系統可以完成階段任務後退出，而成果轉移到論文、學生、基準與下一代專案。名人堂不應用「仍在運行」當作唯一成功標準，也不能把停止維護的原型包裝成可直接採用的產品。

OtterTune 把資料庫旋鈕變成大規模學習問題

商用 DBMS 往往暴露數十到數百個設定，彼此還有非線性交互作用。不同工作負載、資料量與硬體的最佳值不相同，人工反覆測試既慢又難以複製。CMU Database Group 的 OtterTune 專案頁整理了這項研究：收集執行指標與設定，以 machine learning 找出重要旋鈕、比對相似工作負載，再推薦新配置。

二〇一七年 CMU 團隊的自動調優論文把大規模先前工作負載資料引入新部署，目標是減少每個資料庫從零探索的成本。這和今日 AI 平台的經驗重用相似：模型不只看單一執行個體，也利用其他環境的反應建立先驗。但跨環境遷移必須謹慎，版本、硬體與資料分布差異都可能讓相似度失真。

觀測資料的品質決定調優上限

自動調優需要 CPU、I/O、等待事件、buffer 命中、query latency、吞吐與成本等訊號，但指標常有延遲、缺值與版本差異。監控負載本身也會干擾系統。若模型只看到平均值，可能錯過長尾延遲或少數關鍵交易；若把所有指標都餵入，噪音與共線性又會降低穩定度。

因此，Pavlo 路線的重要一環是特徵選擇與 workload characterization。平台需要知道哪些指標代表原因、哪些只是伴隨現象，也要保存配置變更與負載窗口的精確時間線。對 AI 基礎設施團隊來說，這同樣適用於 GPU 排程、向量索引與推論快取：沒有可靠 telemetry，automation 只會把猜測自動化。

目標函數不是只有吞吐量

資料庫調優可以追求 throughput、平均延遲、尾端延遲、雲端成本、能源或穩定性，但這些目標會衝突。把記憶體開到最大可能提高效能，卻壓縮同機其他服務；積極建立索引能加快讀取，卻拖慢寫入並增加儲存；提高並行度可能放大鎖競爭。自治系統必須接受清楚的多目標約束，而不是自行推測企業優先順序。

這也說明為何 human-in-the-loop 在生產環境仍有價值。人類不需要手動試每個參數，但應定義服務水準、成本預算、禁止動作與變更窗口。自治的成熟度不是人越少越好，而是把人從微調操作移到政策與例外管理，同時保留稽核和停止機制。

從外部 tuner 到內建自治

OtterTune 採外部服務觀測並推薦配置，部署門檻較低，也能服務多種現有 DBMS；但外部工具看不到引擎內部所有候選動作，回饋週期也較長。內建自治可以同時調整索引、布局、資源與執行策略，卻需要修改引擎並承擔更大的正確性風險。Pavlo 與合作者長期比較這兩條路線，而不是假設其中一種普遍勝出。

對企業採用而言，外部 tuner 適合先建立只讀建議、影子評估與人工核准；內建機制則應從低風險、可快速回復的動作開始。無論形式，都要記錄「建議了什麼、實際做了什麼、前後負載是否可比」。若缺少這條 lineage，任何效能提升都可能只是流量變少或快取升溫造成的假象。

Database Gym：安全探索需要可重現的環境

線上資料庫不能承受大量隨機嘗試，強化學習或黑箱優化若直接在正式環境探索，代價可能是延遲尖峰與事故。Pavlo 團隊因此研究 database gym：用受控、可重播的負載環境加速建立行為模型，再把候選策略帶到更嚴格的驗證流程。gym 的角色不是完全複製 production，而是讓危險探索先在可回復條件下進行。

這和 AI agent 的 sandbox 原則一致。代理要學會資料操作、migration 或資源調度，應先在代表性資料、故障注入與成本限制中測試。只有通過負向案例、權限邊界與回滾驗證，才適合進入小比例 canary。模擬環境無法證明正式效果，但能排除大量已知不安全策略。

optd：把查詢優化器做成可擴充服務

Pavlo 現在列出的活躍方向之一是 optd optimizer-as-a-service。查詢優化必須在龐大計畫空間中考量 join、索引、快取、硬體與分散式資料位置，成本模型又常與實際執行有落差。optd 嘗試建立高效、可擴充的優化器研究載體，涵蓋 cardinality estimation、adaptive planning、AI-enhanced planning 與 parallel execution。

把 optimizer 抽成服務的好處，是多個引擎可以共享研究成果，也能更快比較估算器與搜尋策略；風險則包括統計資料傳輸、版本耦合、決策延遲與引擎能力差異。若 AI 產生複雜查詢，優化器的重要性只會上升，因為自然語言介面可能放大不必要 join、重複掃描與無界聚合。生成 SQL 不是終點，必須和成本與安全策略共同驗收。

最新研究開始讓大型語言模型參與調優

Pavlo 官方論文清單收錄二〇二六年以大型語言模型和歷史經驗加速自動資料庫調優的研究。這個方向不是讓 LLM 直接對 production 下指令，而是研究它能否從過往配置、工作負載與文字知識提出更好的候選，減少每次重新訓練或盲目搜尋。

LLM 適合整合異質上下文與產生假設，但數值效能仍要由實測決定。版本文件可能過期，模型也可能提出不存在或互斥的參數。合理架構是讓 LLM 位於 proposal layer，由政策檢查、類型驗證、影子 benchmark、canary 與 fresh read-back 決定是否採用。這種分工把生成能力和資料庫的可驗證性接在一起。

BenchBase 與公開課程讓系統研究可比較、可傳承

除了新架構，Pavlo 也投入 benchmark、開源專案與資料庫課程。CMU Database Group 專案清單把 BenchBase、optd 與歷史系統放在同一研究脈絡。BenchBase 提供多種 SQL 工作負載的共同測試框架，讓研究者能比較 DBMS、配置與硬體，而不是每次用不同腳本得出不可重現的結論。

他的課程材料也把 storage、index、optimizer、concurrency control、logging 與 recovery 系統化公開。這種教育產出是基礎設施影響力的一部分：資料庫不是靠少數專家祕技維持，而是透過可重作的實驗與清楚的 mental model 培養下一代工程師。AI 工具可以輔助寫碼，卻不能取代對 transaction、成本模型與故障語意的理解。

OtterTune 的結束帶來哪些務實教訓

第一，技術上可行不等於市場採用自然發生。資料庫調優牽涉最高權限、正式效能與事故責任，客戶導入週期長，還必須證明節省足以覆蓋風險。第二，雲端資料庫供應商會持續把自動化收進原生服務，獨立產品必須找到跨平台、可解釋或更深控制的差異。第三，推薦若需要大量人工審核，價值可能被操作成本吃掉。

但這些商業教訓不否定研究成果。OtterTune 的論文、資料集、方法與人才已進入更廣的自治資料庫領域。評價 AI 基礎設施人物時，應分別看架構影響、開源或學術擴散、產品存續與可驗證客戶成果；把它們壓成單一成敗分數，反而無法學到真正限制。

團隊導入自動調優的安全順序

先建立不可變的 baseline：固定資料集、代表性查詢、版本、硬體、設定與觀察窗口；再以只讀模式收集建議，確認系統理解的負載和 DBA 判斷一致；接著在隔離環境重播，加入高峰、錯誤、長交易與資源競爭；最後才在有回滾、變更窗口與 stop condition 的小範圍 canary 執行。任何一步若無法重現，就不應往下擴大。

驗收也要同時包含效能與正確性。查詢結果、交易一致性、備份恢復、故障切換與監控完整度不能為平均延遲讓路。對 AI 建議而言，還要保存 prompt、模型版本、候選理由與最後執行差異，避免事後只看到參數改了，卻無法知道決策來源。

為何 Andy Pavlo 值得列入 AI 基礎設施名人堂

Pavlo 把自動資料庫管理從模糊願景拆成可研究的控制問題，建立完整 DBMS、調優服務、benchmark、gym 與 optimizer 載體，並持續公開哪些專案結束、哪些假設仍需修正。他的影響同時存在於論文、學生、課程、開源工具與產業對 self-driving database 的定義。

在 agent 能快速生成查詢和操作建議的時代，資料庫更需要受約束的自治，而不是無邊界自動化。Pavlo 的工作提醒我們：真正的 AI 基礎設施不是會提出聰明建議就結束，而是能觀測、驗證、部署、學習，並在出錯時確定地停下與回復。這條工程紀律，遠比「AI 自動調參」的宣傳語更值得保留。

延伸閱讀

若想比較資料庫調優與分析資料產品的共同邏輯，可以接著閱讀Jordan Tigani與BigQuery、MotherDuck：分析資料庫的下一層，對照觀測、查詢、成本與資料治理。

官方與第一方資料

• CMU Computer Science Department：Andrew Pavlo 人物頁
• Andy Pavlo 的 CMU 官方個人頁與現行專案狀態
• CMU Database Group：OtterTune 專案與論文
• Andy Pavlo：Self-Driving DBMS 定義
• CMU Database Group：optd optimizer-as-a-service
• Andy Pavlo：官方論文清單

增量：自動調優的核心是把資料庫決策變成可回放實驗

Andy Pavlo 的 OtterTune、Self-Driving DBMS 與 optd 路線可以再用「觀測—建模—建議—驗證—回復」來整理。系統先收集查詢、資源與延遲資料，再提出索引、配置或計畫建議；變更必須在受控條件下驗證，並能在負載惡化時回到前一版本。AI 只是其中的決策元件，不應取代資料庫管理者的責任與可讀紀錄。

這讓「AI 資料庫」成為可檢查的工程流程，而不是只用 self-driving 形容詞包裝黑箱最佳化。