# クエリオプティマイザ ## 定義 クエリオプティマイザ(Query Optimizer)とは、宣言的なSQLを実行可能な物理プランへ変換する過程で、意味を保ったままプランをより効率的な等価プランへ書き換える機構である。SQLは「what」(何が欲しいか)を指定するのみで「how」(どう計算するか)を指定しないため、クエリ処理は (1) SQLを正準プラン(canonical plan)へ機械的に翻訳、(2) 等価性を保つ書き換え(optimization pass)を適用、(3) 最適化済みプランを物理プランへ写像して実行、の3段階を踏む。[[DuckDB]] v1.5は30以上の最適化パスを実装し、各パスは事前に決められた順序で一度だけ実行される(fixpointまで反復しない)。1パスあたり典型10〜50μs、全体で約1msに収まるよう設計され、予測可能な最適化コストを得る代わりに、パス順序に起因する最適化の取りこぼし(例: 統計ルックアップによるEMPTY_RESULTが上流への伝播に間に合わない)が起こり得る(Source: [[@2026__DiDi__Query Rewriting and Optimization]])。 ## 横断的知見 - **Petrov の教科書的なオプティマイザ定義(統計情報とコストに基づく計画探索)は、DuckDB のパスベース実装(固定順序・非反復)とは異なる最適化モデルを示す**: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] は、クエリオプティマイザを「インデックスのカーディナリティや交点のおおよそのサイズ等の内部統計情報とデータの配置(ノードとその転送コスト)を基準に、使用可能な計画の中から最善の計画を探索・選択する」機構として説明する。これは古典的なコストベース最適化(複数の計画候補をコスト推定で比較し最良のものを選ぶ)の定式化である。対して[[@2026__DiDi__Query Rewriting and Optimization]]が示す DuckDB の実装は、30以上の書き換えパスを事前に決められた順序で1度だけ適用し(fixpoint まで反復しない)、複数の物理計画候補を生成してコスト比較する探索は行わない。両者は同じ『クエリオプティマイザ』という語を、「複数計画の比較選択」(Petrov の教科書的定義)と「等価変換の逐次適用」(DuckDB の実装)という異なるモデルで指している可能性があり、教科書的定義と実装の乖離として記録に値する。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]], [[@2026__DiDi__Query Rewriting and Optimization]]) - **LLMによるクエリ最適化は、DuckDBのパスベース書き換えやPetrovの教科書的コストベース選択とは異なる第3のモデルを提示する**: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]] §3.3.2は、従来の論理最適化が事前定義の書き換えルールまたは学習ベースのルール適用順序決定に、物理最適化が統計データに基づくヒューリスティックまたは学習ベース技法に依存すると整理したうえで、LLMベース手法をモデルに内在するSQL最適化知識を直接活用する第3の系統として位置づける。具体的にはLLM-R2が書き換えルールの適用順序をLLMに決定させ、LLM-QOが演算子と結合順序を含む完全な実行計画を直接生成し、R-Botが検索した書き換え経験に基づき自己内省(self-reflection)を伴う段階的書き換えを行う。これら3手法はいずれも、DuckDBのような事前に固定された順序の書き換えパス適用や、Petrovが説明する統計情報に基づく複数計画のコスト比較選択とは異なり、実行時にLLMが動的に書き換え・計画生成の判断を下す点で異なるモデルを示す。(Source: [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]], [[@2026__DiDi__Query Rewriting and Optimization]]) ## 未解決の問い - fixpointまで反復しない一度きりの順序実行パス設計は、他のDBMS(PostgreSQL・Calcite等のコストベース/ルールベースオプティマイザ)のフレームワークとどう対比されるか。 - パス順序に起因する最適化の取りこぼしを検出・修正する仕組み(再実行トリガーや順序自動調整)はDuckDBに存在するか。 - `duckdb_optimizers()`テーブル関数や`PRAGMA disable_optimizer`によるパス制御は、実運用でどのようなデバッグ・チューニング場面に使われるか。 - DuckDB のパスベース最適化は、Petrov が説明する「複数計画の統計ベース比較選択」を内部的にどこかで行っているか、それとも実装上完全に不要と判断されているか。分散 DBMS(データ配置・転送コストを考慮する必要がある)ではパスベース最適化だけで十分か。 - LLM-R2やLLM-QOが生成する書き換え・実行計画は、DuckDBのパスベース最適化やPetrovの教科書的定義が前提とする意味保存(等価性保証)をどう担保しているか。両ソースの記述からは確認できない。 ## 関連 - ソース: [[@2026__DiDi__Query Rewriting and Optimization]] / [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] / [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]] - 概念: [[クエリ実行プラン]] / [[結合順序最適化]] / [[クエリ非相関化]] - エンティティ: [[DuckDB]] / [[Torsten Grust]] / [[Universität Tübingen]] ## 出典 - [[@2026__DiDi__Query Rewriting and Optimization]](DuckDBのパスベース最適化アーキテクチャを解説する一次ソース、p.02-06) - [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]](§1.1 — 統計情報とコストに基づく古典的なオプティマイザの教科書的定義) - [[@2025__arXiv__A Survey of LLM × DATA - Chapter 3.3 LLM for Data System Optimization]](§3.3.2 — LLMベースのクエリ書き換え・実行計画生成手法、LLM-R2/LLM-QO/R-Bot)