収録問題 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を使います。
customerが存在しない注文も残してcustomer情報を結合したい。適切なのは？
答え： ordersからcustomersへのLEFT JOIN
LEFT JOINは左側の全行を保ち、一致しない右列をNULLにします。
両tableで一致する行だけ取得したい。一般的なjoinは？
答え： INNER JOIN
INNER JOINはjoin条件が一致する組だけを返します。
部署ごとの社員数を集計したい。基本形は？
答え： GROUP BY department_idとCOUNT(*)
GROUP BYで部署単位にまとめCOUNTで各groupの行数を数えます。
集約後、社員数が10人以上の部署だけ残したい。使う句は？
答え： HAVING COUNT(*) >= 10
HAVINGはGROUP BY後の集約結果をfilterします。
重複するcategory値を除いて一覧したい。適切なのは？
答え： SELECT DISTINCT category
DISTINCTは選択列の重複行を除きます。
値がNULLなら0を返したい。適切な関数は？
答え： COALESCE(value, 0)
COALESCEは左から最初の非NULL値を返します。
条件に応じて表示labelを変えたい。標準SQLの式は？
答え： CASE WHEN ... THEN ... END
CASE式は条件分岐した値をquery内で生成します。
文字列の部分一致を検索する基本演算子は？
答え： LIKE
LIKEは%や_のwildcardでpatternを照合します。
2つのSELECT結果を重複除去して結合したい。適切なのは？
答え： UNION
UNIONは互換列の結果を結合し重複を除きます。
安全にuser入力をWHERE条件へ渡す方法は？
答え： driverのparameterized queryを使う
parameter bindingは値とSQL構文を分離しinjectionを防ぎます。
複数の更新を全て成功時だけ確定したい。使う仕組みは？
答え： transaction
transaction内で成功時COMMIT、失敗時ROLLBACKします。
transaction内で一部地点まで戻せるようにしたい。使うものは？
答え： SAVEPOINT
SAVEPOINTを作るとtransaction全体を終えずその地点までrollbackできます。
新規rowへ自動採番primary keyを付ける現代的な定義は？
答え： GENERATED ... AS IDENTITY
identity columnはsequenceを利用した標準的な自動採番を提供します。
email列の重複登録をDBで防ぎたい。適切なconstraintは？
答え： UNIQUE
UNIQUE constraintは指定列の重複を拒否します。
orderが存在しないcustomer_idを参照するのを防ぎたい。使うconstraintは？
答え： FOREIGN KEY
FOREIGN KEYは参照先keyの存在を保証します。
大量INSERTを効率化し全件を別々にcommitしたくない。基本方針は？
答え： batch/COPYを使い適切な単位でtransaction化する
batchやCOPYはround tripとcommit overheadを減らします。
queryの実際の実行計画と時間を確認したい。適切なのは？
答え： EXPLAIN ANALYZE
EXPLAIN ANALYZEはqueryを実行しactual row数や時間を表示するため副作用に注意します。
WHERE user_id = ?が頻繁で選択性が高い。検討するものは？
答え： user_idへのindex
適切なindexは対象rowへのアクセス量を減らせます。
indexを増やしすぎる主な欠点は？
答え： INSERT/UPDATE/DELETEの保守costとstorageが増える
各writeで関連indexも更新されるため、利用queryに基づき選びます。
複合index(a,b)が特に役立つqueryは？
答え： aで絞り、必要に応じてbも条件にするquery
B-tree複合indexは左端列から利用しやすく、列順はqueryに合わせます。
行が頻繁に更新・削除されるtableでVACUUMが必要な理由は？
答え： dead tupleを再利用可能にしMVCC管理を維持する
PostgreSQL MVCCでは古いrow versionが残るためVACUUM/autovacuumが回収を進めます。
planner統計を更新したい。使うcommandは？
答え： ANALYZE
ANALYZEはdata分布統計を収集しplannerの見積りに使われます。
長時間transactionが運用上問題になり得る理由は？
答え： 古いrow versionの回収を妨げ、lockやbloatへ影響する
長いsnapshotはVACUUMの回収を制限し、保持lockも競合を招く場合があります。
同じrowを複数処理者が同時取得しないjob queueで役立つ構文は？
答え： FOR UPDATE SKIP LOCKED
SKIP LOCKEDは他transactionがlock中のrowを飛ばし、queue workerの競合を減らせます。
接続数が増えDB資源を圧迫している。一般的な対策は？
答え： connection poolを使い上限とtimeoutを設ける
poolは接続を再利用しDBへの同時接続を制御します。
復旧可能性を担保するbackup運用として適切なのは？
答え： 定期backupに加えrestore testと保持方針を運用する
backupは実際にrestoreできることを別環境で検証して初めて有効です。
ある時点直前まで復旧するPITRに必要な代表要素は？
答え： base backupと連続的に保管したWAL
base backupへWALをreplayして指定時点まで復元します。
application userへtable操作権限を与える基本方針は？
答え： 必要なschema/table操作だけGRANTする
最小権限によりcredential漏えい時の影響を限定します。
applicationとmigrationでDB roleを分ける利点は？
答え： 通常処理にDDL権限を与えず変更権限を限定できる
runtime roleをread/writeに限定しschema変更は管理経路へ分離できます。
replicaを参照queryへ使う際に注意する点は？
答え： replication lagにより最新writeがまだ見えない可能性
非同期replicationではread-after-write整合性が保証されない場合があります。
productionで危険なDDLを行う前の適切な準備は？
答え： lock影響・実行時間・rollback/restore手順を検証する
DDLはlockやtable rewriteを伴う場合があるため事前検証と監視が必要です。
遅いquery調査でapplication側情報と結び付けるため有効なのは？
答え： query duration、request ID、parameterを秘匿したcontextを記録する
相関IDとdurationを安全に記録するとtraceとDB統計を結び付けられます。
deadlock発生時のapplication対応として適切なのは？
答え： transactionをrollbackし、必要なら限定回数retryする
DBはdeadlock解消のため一方を中止するので、短いtransactionと一貫したlock順序も見直します。
OFFSETが非常に大きいpaginationの問題は？
答え： 読み飛ばすrowが増え遅くなり、同時更新で結果もずれ得る
安定したsort keyを使うkeyset paginationを検討します。
個人情報を含むproduction dataを開発環境で使う際の方針は？
答え： 原則使わず、必要なら承認済み匿名化・最小化dataを使う
開発環境へのdata持出しは漏えいriskを増やすため匿名化とaccess制御が必要です。
部署ごとにsalaryが高い上位3人を取得したい。全体LIMITではなくgroup別順位を付ける方法は？
答え： ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC)で順位を付けて3以下を絞る
window関数で部署ごとのpartition内に順位を付け、外側queryで順位をfilterします。同順位を同じ順位にしたい場合はRANKやDENSE_RANKも検討します。
取引を日時順に並べ、accountごとの累積金額を各行へ表示したい。適切な式は？
答え： SUM(amount) OVER (PARTITION BY account_id ORDER BY occurred_at, id)
window aggregateは元の各行を残したままpartition内の累積値を計算できます。同時刻の順序を安定させるため一意なtie-breakerもORDER BYへ含めます。
複雑な集計queryの中間結果へ名前を付け、同じstatement内で読みやすく参照したい。使う構文は？
答え： WITH句のCTE
CTEはstatement内のqueryへ名前を付け、段階的な処理や再帰queryを表現します。性能面では実行計画を確認し、必要に応じてMATERIALIZED指定等を判断します。
注文が1件以上存在するcustomerだけを返し、注文列自体は取得しない。意図を明確に表す条件は？
答え： WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id)
EXISTSは相関条件を満たすrowの存在を判定します。joinによるcustomer行の重複を避け、存在確認という意図を直接表現できます。
1回の集約で、statusがpaidの件数とfailedの件数を別々の列へ出したい。PostgreSQLで読みやすい方法は？
答え： COUNT(*) FILTER (WHERE status = 'paid')等をstatusごとに使う
aggregateのFILTER句は、同じgroup内で条件別の集約値を明確に記述できます。CASE式による条件集約も移植性が必要な場合の選択肢です。
timestamp列から2026年7月の行を漏れや重複なく取得し、indexも使いやすくしたい。適切な条件は？
答え： created_at >= TIMESTAMP '2026-07-01' AND created_at < TIMESTAMP '2026-08-01'
開始を含み次期間の開始を含まないhalf-open範囲は時刻精度に依存せず月境界を表現します。列へ関数を適用しないため通常のB-tree indexも使いやすい形です。
created_at DESC, id DESCで並べた一覧をkeyset paginationする。次pageの条件として適切なのは？
答え： WHERE (created_at, id) < (:last_created_at, :last_id) ORDER BY created_at DESC, id DESC LIMIT :n
並べ替えと同じ複合keyをcursorに使うと、同時刻の行もidで一意に進められます。方向と比較演算子をORDER BYに合わせ、対応indexも検討します。
更新前後の値がNULLを含む場合も含め、安全に『値が異なる』と判定したい。PostgreSQLで適切なのは？
答え： old_value IS DISTINCT FROM new_value
IS DISTINCT FROMはNULLを比較可能な値として扱い、異なるかどうかを必ずtrue/falseで返します。NULL同士は同じ、NULLと非NULLは異なると判定します。
親tableのrow削除に連動して子rowも削除したいが、誤削除時の影響範囲をschemaで明確にしたい。定義するものは？
答え： foreign keyへON DELETE CASCADEを要件確認の上で設定する
ON DELETE CASCADEは親削除時の子削除をDBの参照整合性規則として定義します。大量cascadeや監査要件を確認し、意図しない親削除への防御も必要です。
UPDATEしたrowのidと更新後statusを追加SELECTなしでapplicationへ返したい。PostgreSQLで使う句は？
答え： UPDATE ... RETURNING id, status
RETURNINGはINSERT・UPDATE・DELETE等で影響を受けたrowの列を同じstatementから返します。生成値の取得や実際の更新対象確認に役立ちます。
emailが既存ならlast_seenだけ更新し、未登録ならINSERTする処理を競合に強く1statementで行いたい。適切なのは？
答え： INSERT ... ON CONFLICT (email) DO UPDATE SET last_seen = EXCLUDED.last_seen
ON CONFLICTはunique indexまたはconstraintとの競合を原子的に処理します。EXCLUDEDから投入予定値を参照し、更新対象列と条件を明示します。
未処理のjobだけをWHERE processed_at IS NULLで頻繁に検索するが、処理済みrowが大半を占める。適したindexは？
答え： WHERE processed_at IS NULLを条件にしたpartial index
partial indexはpredicateを満たすrowだけを保持するため、小さく保ちやすく未処理queue検索に適します。query条件がindex predicateと対応する必要があります。
emailを大文字小文字を区別せず検索するWHERE lower(email) = lower(:email)を高速化したい。検討するindexは？
答え： lower(email)に対するexpression index
queryで使う式と対応するexpression indexを作ると、lower変換後の値をindex検索できます。一意性も大文字小文字非依存にしたい場合はUNIQUE expression indexを検討します。
jsonb列attributesへ包含検索attributes @> :criteriaを頻繁に行う。代表的に検討するindexは？
答え： attributesに対するGIN index
GINはjsonbのkey/value要素に対する包含などの検索を支援します。operator class、index size、write costをquery patternに合わせて選びます。
大きなproduction tableへ通常のread/writeを長時間止めずにindexを追加したい。PostgreSQLで検討するcommandは？
答え： CREATE INDEX CONCURRENTLY
CREATE INDEX CONCURRENTLYはindex構築中も通常の書込みを許可しやすい一方、時間とI/Oが増え、transaction block内で実行できません。失敗時のinvalid index確認も必要です。
productionで総実行時間や平均時間、呼出回数から負荷の大きいSQLを特定したい。代表的なextension/viewは？
答え： pg_stat_statements
pg_stat_statementsは正規化したstatement単位で実行統計を集計します。導入設定、統計reset、期間差分、parameter秘匿を考慮して利用します。
logical replication slotのconsumerが長時間停止し、primary diskのWAL使用量が増え続けている。主な理由は？
答え： slotがconsumer未確認のWALを保持させるため、lagとslot状態の監視・復旧判断が必要
replication slotはconsumerが必要とする位置より新しいWALを再利用させません。停止したslotを放置するとdisk枯渇につながるため、lag・容量alertと安全なdrop/recreate手順が必要です。
web requestが誤ったSQLで長時間実行されたり、DDLがlock待ちし続けたりする影響を限定したい。設定の組合せは？
答え： roleまたはsessionに適切なstatement_timeoutとlock_timeoutを設定する
statement_timeoutはstatement全体の実行時間、lock_timeoutはlock取得待ちを制限します。処理種別ごとに妥当な値を設定し、timeout後のtransaction rollbackも処理します。
一部tableだけ選択して並列restoreできる論理backupを取得したい。代表的な組合せは？
答え： pg_dumpのcustomまたはdirectory formatとpg_restore
pg_dumpのcustom/directory formatはpg_restoreでobject選択や並列restoreができます。大規模環境では物理backupやPITRとの役割分担、restore testも必要です。
同じtableを複数tenantで共有し、通常queryでも接続tenant以外のrowをDB側で見せたくない。PostgreSQLの仕組みは？
答え： Row-Level Securityを有効化し、tenant条件のpolicyを定義する
RLS policyはroleやsession contextに基づいてrowの参照・変更条件をDBで強制できます。ownerやBYPASSRLSの扱い、connection poolでのcontext初期化、policy testが重要です。
地域別、商品別、全体の売上小計を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する
通常の列別統計では相関を独立と見なすことがあります。dependenciesや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ロールへ認めるかという検証と認可の設計が必要です。段階展開と緊急失効手順も用意します。