収録問題 40問 ／ 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制御が必要です。