Q1. PostgreSQL の EXPLAIN ANALYZE 出力で「Rows Removed by Filter: 95000」と表示された場合、最も適切な対応は？
A. shared_buffers を増やす B. フィルタ条件のカラムにインデックスを追加する C. work_mem を増やす D. VACUUM FULL を実行する
答えを見る
正解: B
Rows Removed by Filter が大きいということは、Seq Scan で大量の行を読み込んだ後、フィルタで大半を除去していることを意味する。フィルタ条件のカラムにインデックスを追加することで、必要な行だけを効率的に取得できる。
Q2. 複合インデックスの ESR ルールで、カラムの並び順として正しいのは？
A. Equality → Sort → Range B. Equality → Range → Sort C. Range → Sort → Equality D. Sort → Equality → Range
答えを見る
正解: A
ESR ルール（Equality, Sort, Range）は、等値条件のカラムを先頭に、次にソートカラム、最後に範囲条件のカラムを配置する。この順序により、等値条件でインデックスを絞り込み、ソート済みのデータにアクセスし、範囲フィルタリングを効率的に行える。
Q3. PostgreSQL のカバリングインデックスで INCLUDE 句を使う主な目的は？
A. インデックスの検索速度を向上させる B. Index Only Scan を実現し、テーブルへのランダムI/Oを回避する C. インデックスのサイズを小さくする D. 部分インデックスを作成する
答えを見る
正解: B
INCLUDE 句で追加したカラムはインデックスの検索には使われないが、インデックスリーフノードに格納される。クエリが必要とする全カラムがインデックスに含まれていれば、テーブル本体へのアクセス（ランダムI/O）が不要になり、Index Only Scan で完結する。
Q4. PgBouncer の transaction モードの制限として正しいのは？
A. トランザクションが使えない B. PREPARED STATEMENT に制限がある C. SELECT クエリのみ実行可能 D. コネクション数が物理コネクション数に制限される
答えを見る
正解: B
transaction モードでは、トランザクション完了後にコネクションが他のクライアントに再割り当てされる。そのため、サーバー側の PREPARED STATEMENT がセッション跨ぎで利用できない。PgBouncer 1.21 以降では max_prepared_statements 設定でこの制限を緩和できる。
Q5. コネクションプールサイズの経験則として「connections = (CPU cores * 2) + effective_spindle_count」が示すのは？
A. アプリケーション側の接続数 B. PgBouncer の最大クライアント数 C. データベース側の最適な物理コネクション数 D. レプリカへの接続数
答えを見る
正解: C
この公式はPostgreSQLの公式ドキュメントにも記載される経験則で、DB側が効率的に処理できる最適な同時接続数を示す。CPUコア数の2倍（CPU並列度）にディスクスピンドル数（SSDなら1）を加えた値が目安。これ以上のコネクションはコンテキストスイッチのオーバーヘッドでスループットが低下する。
Q6. レプリケーション遅延が問題になるケースで「Read-after-Write一貫性」を実現する方法は？
A. 常にレプリカから読む B. 最近書き込んだデータはPrimaryから読み、十分時間が経ったらReplicaから読む C. 読み取りのたびにPrimaryとReplicaの両方にクエリする D. レプリケーション遅延を0msに設定する
答えを見る
正解: B
書き込み直後はレプリカへの反映が遅延する可能性があるため、最近書き込んだエンティティに対する読み取りはPrimaryから行う。一定時間（レプリケーション遅延のmax想定値）が経過したらReplicaに切り替える。このパターンにより、一貫性とレプリカの負荷分散を両立できる。
Q7. コンシステントハッシュでノードを1台追加した場合、データ移動が必要なのは全体の約何割か？（N台のクラスタに1台追加）
A. 全データ B. 約 1/N C. 約 50% D. 約 N/(N+1)
答えを見る
正解: B
コンシステントハッシュでは、新ノードは既存ノードの担当範囲の一部のみを引き継ぐ。N台のクラスタに1台追加する場合、移動が必要なデータは全体の約1/(N+1)、概算で約1/N。これに対し、単純なモジュロハッシュでは約(N-1)/N（ほぼ全データ）の移動が必要になる。
Q8. PostgreSQL のレンジパーティションで古いパーティションを削除する最も効率的な方法は？
A. DELETE FROM table WHERE created_at < ‘2023-01-01’ B. TRUNCATE TABLE partition_name C. ALTER TABLE … DETACH PARTITION → DROP TABLE D. VACUUM FULL partition_name
答えを見る
正解: C
DETACH PARTITION でパーティションを親テーブルから切り離し、DROP TABLE で削除すれば、ロック競合なし、VACUUM不要、ストレージ即時解放で瞬時に完了する。DELETEは大量の行を個別に削除するためロック競合が発生し、その後VACUUMも必要になる。