SQLの「入り口」で何が起きているのか？――PostgreSQLクエリパーサの深淵へ
「`SELECT FROM users WHERE id = 1;`」
私たちが何気なく打ち込んでいるこの一行。データベースに投げた瞬間、PostgreSQLは一体何をしていると思いますか？「まあ、適当に解釈してデータを返してくれるんでしょ？」と思っているなら、少しだけ視点を深くしてみましょう。
実は、PostgreSQLが最初にこのSQLを受け取ったとき、真っ先に待ち構えているのが「クエリパーサ（Query Parser）」です。ここはSQLという人間向けの言語を、コンピュータが理解できる「解析ツリー（Parse Tree）」へと変換する、いわばデータベースの玄関口です。
今日は、このクエリパーサが裏側で何を考え、どう働いているのか。実務でパフォーマンスチューニングやトラブルシューティングを行うエンジニアなら知っておくべき「中身の話」をしていこうと思います。
—
1. 玄関先での「検問」：字句解析と構文解析
クエリパーサの仕事は大きく分けて2つあります。
1. 字句解析（Lexical Analysis / Scanning）:
長い文字列を、意味のある最小単位「トークン」に分解します。`SELECT`、“、`FROM`、`users`…といった具合です。もし、ここで定義されていない文字が含まれていれば、その瞬間に「Syntax Error」として弾かれます。
2. 構文解析（Syntax Analysis / Parsing）:
分解されたトークンを、SQLの文法ルール（文法規則）に照らし合わせて、木構造（Parse Tree）へと組み立てます。
ここで重要なのは、この段階では「テーブルが存在するかどうか」や「権限があるか」は一切チェックしていないということです。パーサは純粋に「文法的に正しいか？」だけを見ています。
実践的な視点：なぜパーサを理解すべきか？
たまに、非常に巨大な複雑なSQLを投げた際に「パーサの解析だけで時間がかかってしまった」というケースに出くわすことがあります。特に、数千行にも及ぶ複雑なCASE文や、巨大なサブクエリを生成するORMを使っている場合、パーサはそれらを一生懸命「解析ツリー」にしようと頭を抱えます。
「クエリが遅い」と言われたとき、それが実行（プランニングや実行）の問題なのか、そもそもパーサによる解析コストの問題なのかを見極める視点を持つことは、シニアエンジニアへの第一歩です。
—
2. コードで見てみる：パーサの世界
PostgreSQLのソースコード（C言語）を覗くと、`gram.y` というファイルにその「文法規則」がびっしりと書かれています。
/ 例：簡易的な概念コード /
stmt: SELECT select_no_parens
| SELECT ‘(‘ select_with_parens ‘)’
;
このように、BNF記法に近い形で「SQLはどうあるべきか」が定義されています。もしあなたが、特定のSQL構文がなぜエラーになるのか知りたいなら、この`gram.y`を眺めてみるのが一番の近道です。
また、PostgreSQLには `pg_parse_query` という内部関数があり、これが解析の心臓部となっています。拡張機能（Extension）を作るときなど、SQLをプログラム的にパースしたい場合は、このあたりの構造を理解しておく必要があります。
—
3. 先輩からのアドバイス：現場で役立つポイント
現場で「クエリが動かない！」となったとき、パーサを意識して以下の点を確認してみてください。
- 予約語の衝突:
テーブル名やカラム名に、SQLの予約語（`user`, `group`, `order` など）をそのまま使っていませんか？ パーサはこれらを「コマンドの一部」と見間違えることがあります。もし使わざるを得ない場合は、ダブルクォーテーション(`”`)で囲む習慣をつけましょう。これは、パーサに対して「これは文法要素ではなく、識別子だよ」と教えてあげるための合図です。
- 構文エラーとパーサの限界:
「Syntax Error」が出たとき、エラーメッセージの最後の方に注目してください。PostgreSQLのパーサは非常に優秀で、「どこで解釈が止まったか」を正確に指し示してくれます。エラー箇所が自分の意図とズレているときは、その直前のカンマの打ち忘れや括弧の閉じ忘れを疑うのが鉄則です。
—
最後に：パーサは「規律」を守る守護神
クエリパーサを単なる「SQL変換器」と思わずに、「SQLの正しい書き方を守る規律の守護神」だと思ってみてください。
パーサが厳格であればあるほど、私たちはSQLという言語を使って、データベースに対して曖昧さのない正確な命令を送ることができます。この最初の信頼関係があるからこそ、後のプランナが最適な実行計画を立て、エグゼキュータが高速にデータを運んできてくれるのです。
次にSQLを書くとき、「今、パーサが俺の書いた文字列を一生懸命ツリー構造に組み立ててくれているんだな」と想像してみてください。きっと、より美しく、無駄のないSQLが書けるようになるはずですよ。
それでは、また次回の深掘りでお会いしましょう！
コメント