コネクションとセッション状態・プロトコルパイプライン

クエリより往復が支配する

同じ SQL でも、ネットワークを挟むと実行時間の正体は「クエリの計算量」より「クライアントとサーバーの往復回数（ラウンドトリップ）」になることが多々あります。1 往復の遅延が同一データセンター内で 0.5 ミリ秒、リージョン跨ぎなら数十ミリ秒に達するため、1 件処理するのに 4 往復かかる設計を 1 往復に畳めれば、クエリを最適化するより劇的に速くなります。本稿は DB の ワイヤプロトコル（クライアントとサーバーが交わすバイト列の取り決め）を内部から追い、プリペア・バインド・実行、セッション状態、カーソル、パイプライン化がどこで往復を生み、どう削るかを正確に整理します。

ワイヤプロトコルの段階：パース・バインド・実行

多くの DB のプロトコルは、1 つのクエリ実行を複数のメッセージに分解します。PostgreSQL の拡張クエリプロトコルを例にとると、論理的な段階は次のとおりです。

• Parse：SQL 文字列を受け取り、構文解析・検証してプリペアドステートメント（解析済みの骨格）を作る。プレースホルダ（$1 など）の型もここで確定する。
• Bind：プリペアドステートメントに実引数を束ね、ポータル（実行可能なインスタンス）を作る。最適化（プラン生成）はこの段で行われ得る。
• Execute：ポータルを実行し、結果行（行データ）をクライアントへ返す。取得行数の上限を指定でき、カーソルとして部分取得もできる。
• Sync：処理の区切りを示し、暗黙のトランザクションを閉じてサーバーが「次の入力を受付可能」（ReadyForQuery）を返す。エラー時はこの Sync まで以降の要求が読み飛ばされる。

Parse  ("SELECT * FROM orders WHERE customer_id = $1")  -- 骨格を1回作る
Bind   ($1 = 42)                                        -- 値を束ねてポータル化
Execute                                                  -- 実行して行を返す
Sync                                                     -- 区切り

素朴に書くと各段で往復が発生しますが、ドライバは複数メッセージを 1 つの TCP 送信にまとめ、最後にまとめて応答を読みます。重要なのは、段が分かれていること自体がパイプライン化の余地を作る点です。なお値を SQL 文字列へ文字列連結せずプレースホルダで分離するため、プリペアドステートメントは SQL インジェクション耐性の根拠にもなります。

プリペアドステートメントとプラン再利用

Parse の成果物であるプリペアドステートメントは、同じ骨格のクエリを値だけ変えて何度も実行するときに効きます。骨格を一度だけ解析・最適化し、以後はバインド値を送るだけで再実行できるため、パース・最適化の CPU と、プランキャッシュ自体への内部ロック競合を節約できます（→ プランキャッシュとパラメータスニッフィングの内部）。

プリペアには 2 系統あります。PREPARE 文で明示するサーバーサイド・プリペアと、ドライバが内部で名前付きステートメントを張る暗黙のプリペアです。後者は「初回は Parse+Bind+Execute、2 回目以降は Bind+Execute だけ」という最適化を透過的に行います。

セッション状態：接続は使い回せても状態は引き継げない

ワイヤプロトコルの設計を理解するうえで決定的なのが、セッション状態という概念です。1 本の接続には、その接続に紐づく可変状態がぶら下がります。代表例は次のとおりです。

ここがコネクションプーリング（→ コネクションプーリング）の設計を縛ります。プールは接続を借りて返すことで確立コストを償却しますが、返す前にセッション状態をリセットしないと、次に借りた処理へ前の状態が漏れます。トランザクションを開けっぱなしで返せば次の利用者が巻き込まれ、一時テーブルやセッション変数が残れば不可解なバグになります。だからこそプーラーは返却時に未完トランザクションをロールバックし、設定を初期化します。「接続は共有資源だが、セッション状態は私物」という非対称性が要点です。トランザクションそのものの境界とコミットの意味は別稿に譲ります（→ トランザクション）。

カーソル：結果を小出しにして往復とメモリを抑える

巨大な結果集合を一度に返すと、サーバーは全行を作り切るまで応答を返せず、クライアントも全行をメモリに載せます。カーソルは結果集合に対する現在位置のついた窓で、Execute の取得行数上限や FETCH によって部分的に行を取り出せます。これにより最初の 1 行までの待ち時間（time-to-first-row）が縮み、メモリ使用も一定に保てます。

ただしカーソルもセッション状態です。多くの DB ではトランザクション内でのみ生存する（WITHOUT HOLD）ため、FETCH のたびに別接続へ振り分けるような構成では使えません。また 1 行ずつ FETCH すれば行数ぶんの往復が発生するので、実務ではフェッチサイズを数百〜数千に設定し、まとめて取得して往復を償却します。小さすぎれば往復過多、大きすぎればメモリ過多という、典型的なバッチサイズのトレードオフです。

-- フェッチサイズ=1000 のとき
FETCH 1000  -- 1往復で1000行
FETCH 1000  -- 次の1000行
...

パイプライン化：応答を待たずに送る

ワイヤプロトコルが段に分かれている恩恵が最大化されるのがパイプライン化です。通常は「要求を送る → 応答を待つ → 次を送る」と直列に進み、N 件の操作で N 往復します。パイプライン化では、前の応答を待たずに次の要求をネットワークへ流し込み、応答はあとでまとめて読みます。要求と応答の順序対応はプロトコルが保証するため、論理的な正しさは保たれます。

効くのは操作どうしに結果依存がない場合です。たとえば 1000 件の独立した INSERT は、1 件ずつ往復させると 1000 往復ですが、パイプラインで一気に流せば、ネットワーク遅延の支配は実質 1 往復ぶんに縮みます。「直前の取得結果を見て次の SQL を決める」ような依存がある処理は畳めません。

まとめ