収録問題 80問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
employees表から全列ではなくnameとemailだけ取得したい。適切なSELECTはどれですか？
答え： SELECT name, email FROM employees
必要な列を明示すると転送量と依存範囲を抑えられます。
activeがtrueの行だけ取得したい。使う句はどれですか？
答え： WHERE active = true
WHEREは集約前の行を条件で絞ります。
created_atの新しい順に並べたい。適切なのはどれですか？
答え： ORDER BY created_at DESC
DESCは降順で日時なら新しい値が先になります。
結果を最大100行に制限したい。PostgreSQLで使う句はどれですか？
答え： LIMIT 100
LIMITは返却行数の上限を指定します。
NULLかどうかを正しく判定する条件はどれですか？
答え： column IS NULL
NULLは通常の等価比較ではなくIS NULLを使います。
顧客が存在しない注文も残して顧客情報を結合したい。適切なのはどれですか？
答え： ordersからcustomersへのLEFT JOIN
LEFT JOINは左側の全行を保ち、一致しない右列をNULLにします。
両テーブルで一致する行だけ取得したい。一般的な結合はどれですか？
答え： INNER JOIN
INNER JOINは結合条件が一致する組だけを返します。
部署ごとの社員数を集計したい。基本形はどれですか？
答え： GROUP BY department_idとCOUNT(*)
GROUP BYで部署単位にまとめCOUNTで各グループの行数を数えます。
集約後、社員数が10人以上の部署だけ残したい。使う句はどれですか？
答え： HAVING COUNT(*) >= 10
HAVINGはGROUP BY後の集約結果をfilterします。
重複するcategory値を除いて一覧したい。適切なのはどれですか？
答え： SELECT DISTINCT category
DISTINCTは選択列の重複行を除きます。
値がNULLなら0を返したい。適切な関数はどれですか？
答え： COALESCE(value, 0)
COALESCEは左から最初の非NULL値を返します。
条件に応じて表示ラベルを変えたい。標準SQLの式はどれですか？
答え： CASE WHEN ... THEN ... END
CASE式は条件分岐した値をクエリ内で生成します。
文字列の部分一致を検索する基本演算子はどれですか？
答え： LIKE
LIKEは%や_のwildcardでpatternを照合します。
2つのSELECT結果を重複除去して結合したい。適切なのはどれですか？
答え： UNION
UNIONは互換列の結果を結合し重複を除きます。
安全にユーザー入力をWHERE条件へ渡す方法はどれですか？
答え： driverのパラメータ化クエリを使う
parameter bindingは値とSQL構文を分離しinjectionを防ぎます。
複数の更新を全て成功時だけ確定したい。使う仕組みはどれですか？
答え： transaction
トランザクション内で成功時COMMIT、失敗時ROLLBACKします。
トランザクション内で一部地点まで戻せるようにしたい。使うものはどれですか？
答え： SAVEPOINT
SAVEPOINTを作るとトランザクション全体を終えずその地点までロールバックできます。
新規行へ自動採番主キーを付ける現代的な定義はどれですか？
答え： GENERATED ... AS IDENTITY
アイデンティティ列はシーケンスを利用した標準的な自動採番を提供します。
email列の重複登録をDBで防ぎたい。適切な制約はどれですか？
答え： UNIQUE
UNIQUE 制約は指定列の重複を拒否します。
orderが存在しないcustomer_idを参照するのを防ぎたい。使う制約はどれですか？
答え： FOREIGN KEY
FOREIGN KEYは参照先キーの存在を保証します。
大量INSERTを効率化し全件を別々にコミットしたくない。基本方針はどれですか？
答え： batch/COPYを使い適切な単位でトランザクション化する
バッチやCOPYはround tripとcommit overheadを減らします。
クエリの実際の実行計画と時間を確認したい。適切なのはどれですか？
答え： EXPLAIN ANALYZE
EXPLAIN ANALYZEはクエリを実行しactual row数や時間を表示するため副作用に注意します。
WHERE user_id = ?が頻繁で選択性が高い。検討するものはどれですか？
答え： user_idへのインデックス
適切なインデックスは対象行へのアクセス量を減らせます。
インデックスを増やしすぎる主な欠点はどれですか？
答え： INSERT/UPDATE/DELETEの保守コストとストレージが増える
各writeで関連インデックスも更新されるため、利用クエリに基づき選びます。
複合index(a,b)が特に役立つクエリはどれですか？
答え： aで絞り、必要に応じてbも条件にするクエリ
B-tree複合インデックスは左端列から利用しやすく、列順はクエリに合わせます。
行が頻繁に更新・削除されるテーブルでVACUUMが必要な理由はどれですか？
答え： dead tupleを再利用可能にしMVCC管理を維持する
PostgreSQL MVCCでは古い行バージョンが残るためVACUUM/autovacuumが回収を進めます。
プランナー統計を更新したい。使うコマンドはどれですか？
答え： ANALYZE
ANALYZEはデータ分布統計を収集しプランナーの見積りに使われます。
長時間トランザクションが運用上問題になり得る理由はどれですか？
答え： 古い行バージョンの回収を妨げ、ロックや肥大化へ影響する
長いsnapshotはVACUUMの回収を制限し、保持ロックも競合を招く場合があります。
同じ行を複数処理者が同時取得しないジョブキューで役立つ構文はどれですか？
答え： FOR UPDATE SKIP LOCKED
SKIP LOCKEDは他トランザクションがロック中の行を飛ばし、キューワーカーの競合を減らせます。
接続数が増えDB資源を圧迫している。一般的な対策はどれですか？
答え： connection poolを使い上限とtimeoutを設ける
poolは接続を再利用しDBへの同時接続を制御します。
復旧可能性を担保するバックアップ運用として適切なのはどれですか？
答え： 定期バックアップに加えリストアテストと保持方針を運用する
バックアップは実際にリストアできることを別環境で検証して初めて有効です。
ある時点直前まで復旧するPITRに必要な代表要素はどれですか？
答え： ベースバックアップと連続的に保管したWAL
ベースバックアップへWALをreplayして指定時点まで復元します。
アプリケーション用ユーザーへテーブル操作権限を与える基本方針はどれですか？
答え： 必要なschema/table操作だけGRANTする
最小権限により認証情報漏えい時の影響を限定します。
アプリケーションとマイグレーションでDBロールを分ける利点はどれですか？
答え： 通常処理にDDL権限を与えず変更権限を限定できる
ランタイムロールをread/writeに限定しスキーマ変更は管理経路へ分離できます。
レプリカを参照クエリへ使う際に注意する点はどれですか？
答え： replication lagにより最新writeがまだ見えない可能性
非同期replicationではread-after-write整合性が保証されない場合があります。
本番で危険なDDLを行う前の適切な準備はどれですか？
答え： ロック影響・実行時間・rollback/restore手順を検証する
DDLはロックやテーブルの書き換えを伴う場合があるため事前検証と監視が必要です。
遅いクエリ調査でアプリケーション側情報と結び付けるため有効なのはどれですか？
答え： query duration、リクエスト ID、パラメータを秘匿したコンテキストを記録する
相関IDとdurationを安全に記録するとtraceとDB統計を結び付けられます。
デッドロック発生時のアプリケーション対応として適切なのはどれですか？
答え： トランザクションをロールバックし、必要なら限定回数retryする
DBはデッドロック解消のため一方を中止するので、短いトランザクションと一貫したロック順序も見直します。
OFFSETが非常に大きいページネーションの問題はどれですか？
答え： 読み飛ばす行が増え遅くなり、同時更新で結果もずれ得る
安定したsort keyを使うキーセットページネーションを検討します。
個人情報を含む本番データを開発環境で使う際の方針はどれですか？
答え： 原則使わず、必要なら承認済み匿名化・最小化データを使う
開発環境へのデータ持出しは漏えいリスクを増やすため匿名化とアクセス制御が必要です。
部署ごとにsalaryが高い上位3人を取得したい。全体LIMITではなくグループ別順位を付ける方法はどれですか？
答え： ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC)で順位を付けて3以下を絞る
window関数で部署ごとのpartition内に順位を付け、外側クエリで順位をfilterします。同順位を同じ順位にしたい場合はRANKやDENSE_RANKも検討します。
取引を日時順に並べ、アカウントごとの累積金額を各行へ表示したい。適切な式はどれですか？
答え： SUM(amount) OVER (PARTITION BY account_id ORDER BY occurred_at, id)
window aggregateは元の各行を残したままpartition内の累積値を計算できます。同時刻の順序を安定させるため一意なtie-breakerもORDER BYへ含めます。
複雑な集計クエリの中間結果へ名前を付け、同じステートメント内で読みやすく参照したい。使う構文はどれですか？
答え： WITH句のCTE
CTEはステートメント内のクエリへ名前を付け、段階的な処理や再帰クエリを表現します。性能面では実行計画を確認し、必要に応じてMATERIALIZED指定等を判断します。
注文が1件以上存在するcustomerだけを返し、注文列自体は取得しない。意図を明確に表す条件はどれですか？
答え： WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id)
EXISTSは相関条件を満たす行の存在を判定します。結合によるcustomer行の重複を避け、存在確認という意図を直接表現できます。
1回の集約で、ステータスがpaidの件数とfailedの件数を別々の列へ出したい。PostgreSQLで読みやすい方法はどれですか？
答え： COUNT(*) FILTER (WHERE status = 'paid')等をステータスごとに使う
aggregateのFILTER句は、同じグループ内で条件別の集約値を明確に記述できます。CASE式による条件集約も移植性が必要な場合の選択肢です。
タイムスタンプ列から2026年7月の行を漏れや重複なく取得し、インデックスも使いやすくしたい。適切な条件はどれですか？
答え： created_at >= TIMESTAMP '2026-07-01' AND created_at < TIMESTAMP '2026-08-01'
開始を含み次期間の開始を含まないhalf-open範囲は時刻精度に依存せず月境界を表現します。列へ関数を適用しないため通常のB-tree indexも使いやすい形です。
created_at DESC, id DESCで並べた一覧をキーセットページネーションする。次ページの条件として適切なのはどれですか？
答え： WHERE (created_at, id) < (:last_created_at, :last_id) ORDER BY created_at DESC, id DESC LIMIT :n
並べ替えと同じ複合キーをcursorに使うと、同時刻の行もidで一意に進められます。方向と比較演算子をORDER BYに合わせ、対応インデックスも検討します。
更新前後の値がNULLを含む場合も含め、安全に『値が異なる』と判定したい。PostgreSQLで適切なのはどれですか？
答え： old_value IS DISTINCT FROM new_value
IS DISTINCT FROMはNULLを比較可能な値として扱い、異なるかどうかを必ずtrue/falseで返します。NULL同士は同じ、NULLと非NULLは異なると判定します。
親テーブルの行削除に連動して子行も削除したいが、誤削除時の影響範囲をスキーマで明確にしたい。定義するものはどれですか？
答え： 外部キーへON DELETE CASCADEを要件確認の上で設定する
ON DELETE CASCADEは親削除時の子削除をDBの参照整合性規則として定義します。大量cascadeや監査要件を確認し、意図しない親削除への防御も必要です。
UPDATEした行のidと更新後ステータスを追加SELECTなしでアプリケーションへ返したい。PostgreSQLで使う句はどれですか？
答え： UPDATE ... RETURNING id, status
RETURNINGはINSERT・UPDATE・DELETE等で影響を受けた行の列を同じステートメントから返します。生成値の取得や実際の更新対象確認に役立ちます。
emailが既存ならlast_seenだけ更新し、未登録ならINSERTする処理を競合に強く1つのステートメントで行いたい。適切なのはどれですか？
答え： INSERT ... ON CONFLICT (email) DO UPDATE SET last_seen = EXCLUDED.last_seen
ON CONFLICTはunique indexまたは制約との競合を原子的に処理します。EXCLUDEDから投入予定値を参照し、更新対象列と条件を明示します。
未処理のジョブだけをWHERE processed_at IS NULLで頻繁に検索するが、処理済み行が大半を占める。適したインデックスはどれですか？
答え： WHERE processed_at IS NULLを条件にした部分インデックス
部分インデックスは条件を満たす行だけを保持するため、小さく保ちやすく未処理キュー検索に適します。クエリ条件がインデックス条件と対応する必要があります。
emailを大文字小文字を区別せず検索するWHERE lower(email) = lower(:email)を高速化したい。検討するインデックスはどれですか？
答え： lower(email)に対する式インデックス
クエリで使う式と対応する式インデックスを作ると、lower変換後の値をインデックス検索できます。一意性も大文字小文字非依存にしたい場合はUNIQUE 式インデックスを検討します。
jsonb列attributesへ包含検索attributes @> :criteriaを頻繁に行う。代表的に検討するインデックスはどれですか？
答え： attributesに対するGINインデックス
GINはjsonbのkey/value要素に対する包含などの検索を支援します。operator class、index size、write costをクエリパターンに合わせて選びます。
大きな本番テーブルへ通常のread/writeを長時間止めずにインデックスを追加したい。PostgreSQLで検討するコマンドはどれですか？
答え： CREATE INDEX CONCURRENTLY
CREATE INDEX CONCURRENTLYはインデックス構築中も通常の書込みを許可しやすい一方、時間とI/Oが増え、トランザクションブロック内では実行できません。失敗時に無効なインデックスが残っていないかの確認も必要です。
本番で総実行時間や平均時間、呼出回数から負荷の大きいSQLを特定したい。代表的な拡張機能・ビューはどれですか？
答え： pg_stat_statements
pg_stat_statementsは正規化したステートメント単位で実行統計を集計します。導入設定、統計reset、期間差分、パラメータ秘匿を考慮して利用します。
論理レプリケーションスロットのコンシューマーが長時間停止し、プライマリのディスクのWAL使用量が増え続けている。主な理由はどれですか？
答え： スロットがコンシューマー未確認のWALを保持させるため、lagとスロット状態の監視・復旧判断が必要
レプリケーションスロットはコンシューマーが必要とする位置より新しいWALを再利用させません。停止したスロットを放置するとディスク枯渇につながるため、lag・容量アラートと安全なdrop/recreate手順が必要です。
Webリクエストが誤ったSQLで長時間実行されたり、DDLがロック待ちし続けたりする影響を限定したい。設定の組合せはどれですか？
答え： ロールまたはセッションに適切なstatement_timeoutとlock_timeoutを設定する
statement_timeoutはステートメント全体の実行時間、lock_timeoutはロック取得待ちを制限します。処理種別ごとに妥当な値を設定し、timeout後のトランザクションロールバックも処理します。
一部テーブルだけ選択して並列リストアできる論理バックアップを取得したい。代表的な組合せはどれですか？
答え： pg_dumpのcustomまたはdirectory formatとpg_restore
pg_dumpのcustom/directory formatはpg_restoreでオブジェクト選択や並列リストアができます。大規模環境では物理バックアップやPITRとの役割分担、リストアテストも必要です。
同じテーブルを複数テナントで共有し、通常クエリでも接続テナント以外の行をDB側で見せたくない。PostgreSQLの仕組みはどれですか？
答え： Row-Level Securityを有効化し、テナント条件のポリシーを定義する
RLSポリシーはロールやセッションコンテキストに基づいて行の参照・変更条件をDBで強制できます。オーナーやBYPASSRLSの扱い、connection poolでのコンテキスト初期化、ポリシーテストが重要です。
地域別、商品別、全体の売上小計を1回の集計で返したい。適切なSQL機能はどれですか？
答え： GROUPING SETSを使う
GROUPING SETSは複数のグループ化単位を1つのGROUP BYで表現できます。ROLLUPやCUBEも要件に合う場合があります。
顧客ごとに直近3件の注文を取得し、注文がない顧客も残したい。適した構成はどれですか？
答え： 顧客からLEFT JOIN LATERALし、相関した注文副問い合わせをORDER BYとLIMIT 3で絞る
LATERAL副問い合わせは左側の顧客行を参照できます。LEFT JOINにすると副問い合わせが0件でも顧客を保持できます。
親子関係を再帰CTEでたどる際、データ不備による循環で処理が終わらない事態を防ぎたい。適切なのはどれですか？
答え： 訪問済み経路を追跡するか、対応バージョンではCYCLE句で循環を検出する
循環し得るグラフでは、経路配列などによる訪問済み判定またはCYCLE句を使います。通常データでの深さ上限も防御として検討します。
取込元のデータには、同じキーの行が複数含まれることがあります。これをMERGEするとき、更新対象が曖昧にならないようにする中核の対策はどれですか？
答え： 取込元をキーごとに検証・重複排除し、1対象行へ複数候補行が対応しないようにする
MERGEは候補変更行ごとに最初に真となるWHENを実行しますが、同じ対象行を複数回変更する入力はエラーや曖昧な仕様の原因になります。取込元の一意性を先に保証します。
PostgreSQL 18でCSV取込時の型変換エラー行を隔離しつつ、許容件数を超えたら処理を失敗させたい。適切なのはどれですか？
答え： COPY FROMでON_ERROR ignoreとREJECT_LIMITを設定し、除外件数も監視する
PostgreSQL 18のCOPY FROMは変換エラー行を無視するON_ERRORと上限を設けるREJECT_LIMITを組み合わせられます。業務検証エラーまで自動的に扱う機能ではありません。
同じ会議室の予約時間帯が重ならないことを、同時登録時もDBで保証したい。適切なのはどれですか？
答え： 範囲型とGiSTを利用したEXCLUDE制約を定義する
EXCLUDE制約は、同一会議室かつ時間範囲が重なる組合せをDBで拒否できます。単純な事前SELECTより並行実行に強い設計です。
PostgreSQL 18で契約IDごとの有効期間が重ならないことをキー制約として表したい。検討する構文はどれですか？
答え： UNIQUEまたはPRIMARY KEYの期間列にWITHOUT OVERLAPSを指定する
PostgreSQL 18ではUNIQUE・PRIMARY KEYの末尾の範囲列へWITHOUT OVERLAPSを指定できます。採用前に対象環境のメジャーバージョンを確認します。
集計用マテリアライズドビューを参照停止なしで更新したい。REFRESH MATERIALIZED VIEW CONCURRENTLYの前提はどれですか？
答え： 全行を対象とし、列名だけで構成された適切なUNIQUEインデックスがある
CONCURRENTLYには、式やWHEREを使わず全行を一意に識別するUNIQUEインデックスが必要です。ビューは事前にデータ投入済みである必要もあります。
PostgreSQL 18で、生成順に近い並びを持つUUIDをDB側で作り、ランダムUUIDよりB-treeの局所性を改善したい。適切なのはどれですか？
答え： uuidv7()
PostgreSQL 18のuuidv7()は時系列に並べやすいUUIDを生成します。ただし連番ではなく、時刻情報の露出や対応バージョンを設計時に評価します。
PostgreSQL 18の仮想生成列を採用する前に確認すべき性質はどれですか？
答え： 値は保存時ではなく読取り時に計算され、STOREDとはCPU・記憶領域の特性が異なる
仮想生成列は参照時に式を評価します。読取り頻度、計算量、索引要件、レプリケーションなどを確認し、必要ならSTOREDを選びます。
PostgreSQL 18でB-tree索引(a, b)に対しbだけを絞る検索がある。Skip Scanを期待する際の判断として適切なのはどれですか？
答え： aの種類が少ないなど採算が合う場合にプランナが選ぶため、EXPLAINで実計画を確認する
Skip Scanは先頭列の値ごとに内部探索を繰り返す最適化です。先頭列の種類が多いと不利なため、統計と実行計画に基づいて索引を選びます。
PostgreSQL 18でUPDATE前後の値を監査イベントへ渡すため、追加SELECTなしで同時に返したい。適切なのはどれですか？
答え： RETURNINGでOLDとNEWの値を明示的に参照する
PostgreSQL 18ではINSERT・UPDATE・DELETE・MERGEのRETURNINGでOLDとNEWを明示できます。利用時は接続先バージョンと列名衝突を確認します。
国と都道府県のように強く相関する列を同時に絞ると、推定行数が実測から大きく外れる。まず検討するものはどれですか？
答え： 対象列にCREATE STATISTICSで拡張統計を作成し、ANALYZEする
通常の列別統計では相関を独立と見なすことがあります。依存関係やMCVなどの拡張統計は複数列の関係をプランナへ伝えます。
PostgreSQL 18の非同期I/Oを本番へ導入する際、適切な進め方はどれですか？
答え： 対応ビルドとOSを確認し、io_methodなどを段階的に設定して実ワークロードの待機時間・遅延・資源使用量を比較する
非同期I/Oの効果はOS、ストレージ、走査やVACUUMの比率で変わります。再起動要否と対応方式を確認し、負荷試験と段階展開で判断します。
接続プールの利用者がトランザクションを開いたまま処理を止め、ロックと不要行回収を長時間妨げている。直接的な防御設定はどれですか？
答え： 役割や接続用途に合わせてidle_in_transaction_session_timeoutを設定する
idle_in_transaction_session_timeoutは開いたトランザクション内で待機し続けるセッションを終了します。プール側の再接続動作と業務処理時間を考慮して設定します。
論理レプリケーションの発行元を待機系へ切り替えた後も購読を継続したい。計画切替前の重要確認はどれですか？
答え： failover対応スロットが待機系へ同期され、syncedかつ有効で切替可能な状態か確認する
論理スロットの同期は非同期です。購読が必要とするスロットを特定し、待機系のpg_replication_slotsで同期済み・非一時・無効化理由なしを確認します。
DB全体で、通常問い合わせ・VACUUM・WAL書込みなどのI/O傾向を処理種別ごとに把握したい。まず参照するビューはどれですか？
答え： pg_stat_io
pg_stat_ioはバックエンド種別、I/O対象、コンテキスト別の累積統計を提供します。期間差分を取り、OS・ストレージ指標や個別SQLの計測と組み合わせます。
大規模表へ外部キーを追加したいが、長時間の検査を変更作業から分離したい。適切な段階的手順はどれですか？
答え： 制約をNOT VALIDで追加し、既存違反を確認・修正してからVALIDATE CONSTRAINTする
NOT VALIDで追加した外部キーも新規・更新行には適用されます。既存行の検査をVALIDATEへ分離し、ロック時間と負荷を計画できます。
本番でEXPLAIN ANALYZEを使う前に、UPDATEやDELETEを含むSQLについて注意すべき点はどれですか？
答え： SQLは実際に実行されるため、副作用を避ける検証環境やBEGIN後のROLLBACKなどを計画する
EXPLAIN ANALYZEは実測のため文を実行します。ロールバックでもロック、トリガー、外部副作用、シーケンスなどは別途考慮が必要です。
PostgreSQL 18のOAuth認証を導入する際、アクセストークンを受け取れるだけで十分と考えるのが危険な理由はどれですか？
答え： 検証ライブラリ、発行者・対象者・期限・権限対応、TLS、失効時の運用まで含めて信頼境界を設計する必要がある
OAuthは認証情報の形式を変えるだけでなく、誰のどのトークンをどのDBロールへ認めるかという検証と認可の設計が必要です。段階展開と緊急失効手順も用意します。