初級ではDBを「整理された台帳」と捉えました。中級では、リレーショナルの基本・速さ・正しさを見ます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
多くのWebサービスの中心にあるのはリレーショナルDB（RDB）。データを表（テーブル）に持ち、表どうしをキーで関連づけます。
- 主キー — 各行を一意に識別する項目（例：ユーザーID）
- 外部キー — 別の表の主キーを指して関連づける（例：注文の「ユーザーID」）
- 正規化 — 同じデータの重複を減らし、矛盾が起きにくい形に整理する
登場人物メモ:
- ※1 インデックス（B-tree） — 木構造で範囲・一致を素早く探す索引。書き込みは少し重くなる
- ※2 トランザクション（ACID） — 原子性・一貫性・独立性・永続性を満たす処理のまとまり
この部分をもっと深く（上級）
多数のトランザクションが同時に走る中で、正しさ（分離性）をどう保つか。
- MVCC — 行の複数版を保持し、読み手はスナップショットを読む。読み書きが互いをブロックしにくい
- ロックとラッチ — 論理的な整合のためのロックと、内部データ構造を守る短命のラッチは別物
- 分離レベルの実体 — READ COMMITTED / REPEATABLE READ / SERIALIZABLE を、MVCCやロックでどう実現するか
やさしく言うと（初級）
よく整理された台帳や図書館を想像してください。棚（※1 テーブル）に、1件ずつの記録（※2 行）が並び、それぞれに項目（列）がある。DBは、この整理された状態を保ち、探す・並べる・絞り込むのが得意です。
たくさんの行から目的の1件を速く見つけるために、索引（※3 インデックス） を使います。本の巻末索引と同じ発想です。
登場人物メモ:
- ※1 テーブル — 同じ種類のデータを集めた表（例：ユーザー表、注文表）
- ※2 行（レコード） — 表の1件分（例：ユーザー1人）
- ※3 インデックス — 素早く探すための索引
仕事の流れ
- バックから SQL を受ける（
SELECT／INSERTなど） - 実行計画を立て、インデックスが使えるかを判断する
- 使えれば索引で該当行へ、使えなければフルスキャン（遅い）
アニメーション『インデックスと全表走査』を開く
- 更新系はトランザクションでまとめ、確定（コミット）で永続化する
トランザクションの核が原子性（Atomicity）。「全部成功か、全部なかったことに」で、送金のように「引く」だけ成功して「足す」が失敗、という中途半端を防ぎます。
アニメーション『トランザクション（全部か、なしか）』を開く
この部分をもっと深く（上級）
- パース — SQLを構文木に
- オプティマイザ — 統計情報をもとにコストベースで複数の実行計画を比較し、最良を選ぶ
- 実行計画 — インデックス走査／シーケンシャルスキャン／各種JOIN（ネステッドループ・ハッシュ・マージ）を組む
- 実行 — バッファプール（メモリ上のページキャッシュ）を介してストレージにアクセス
- コミット — WAL に先行して記録し、耐久性を確保
やさしく言うと（初級）
- バックエンドから「この条件のデータを探して」と頼まれる（※4 SQL）
- インデックスを使って素早く該当行を見つける
- 並べ替え・絞り込みをして返す
- 書き込みの依頼なら、記録して保存する（消えないように）
登場人物メモ:
- ※4 SQL — DBへのお願いを書くための言葉（「この条件で探して」「これを保存して」）
速さと正しさ
- インデックス設計 — よく使う検索条件に合わせて張る。多すぎると書き込みが重い
- ロック／独立性 — 同時更新の衝突を防ぐが、待ち合わせがデッドロックを生むことも
- レプリケーション — 同じDBの複製を用意し、読み取りを分散／障害に備える
- シャーディング — データを複数に分割して1台の限界を超える（運用は複雑）
- NoSQLとの使い分け — 表に馴染まないデータ（大量ログ・柔軟な構造）には別種のDBも
この部分をもっと深く（上級）
- B+木 — 葉に実データ（またはポインタ）を並べ、範囲検索と順次走査に強い
- インデックス種類 — B+木のほか、ハッシュ、GiST、全文、カバリングインデックス
- 分離の異常 — ダーティリード／ノンリピータブルリード／ファントム。どれを許すかが分離レベル
- 統計とプラン — 統計が古いと最適でない計画を選ぶ（プラン劣化）
- バッファ管理 — ページの置き換え、チェックポイント、ダーティページのフラッシュ
やさしく言うと（初級）
- DB — 表の形の構造データ（ユーザー・注文など）を、探しやすく保管
- キャッシュ — よく使う答えを一時的に手元に（速いが消えてよい）
- ストレージ — 画像・動画などの大きな塊（表には向かない）
「何でもDBに入れる」のではなく、向き不向きで置き場所を分けます。
⚠️ うまくいかないとき
- フルスキャンで遅い — インデックス不足／条件の書き方でインデックスが効かない
- デッドロック — 複数トランザクションが互いのロックを待って止まる
- N+1問題 — アプリ側が行ごとにクエリを乱発（JOINやまとめ取得で回避）
- 整合性の乱れ — キャッシュやレプリカとの時間差（stale）を考慮していない
この部分をもっと深く（上級）
- レプリケーション — 同期／非同期。非同期は遅延（レプリカラグ）で古い読みが起きる
- シャーディング — キーで分割。クロスシャードのJOINやトランザクションが難所
- 合意 — 分散で1つの真実を決めるための Raft／Paxos
- CAP／PACELC — 分断時に一貫性か可用性か。平常時も遅延と一貫性のトレードオフがある
- ホットスポット — 特定キーへの集中で、分割しても偏る
やさしく言うと（初級）
- 見つからない — 条件に合う行が無い（データ未登録／条件ミス）
- 遅い — インデックスが無く、端から全部見ている
- 重複・矛盾 — 同じデータが二重に入る（設計や制約で防ぐ）
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. トランザクションの「ACID」のうち、「途中で失敗したら全部なかったことにする（中途半端に残さない）」性質はどれ？
問2. インデックスが効かず、全行を順に調べてしまう状態を何と呼ぶ？
問3. 別の表の主キーを指して、2つの表を関連づける項目を何という？
問4. ACIDのうち「確定（コミット）した変更は障害が起きても失われない」という性質はどれ？
問5. 「デッドロック」とはどんな状態か？
問6. 「N+1問題」の説明として正しいのは？
問7. データの重複を減らし、更新時の矛盾が起きにくい形に表を整理することを何と呼ぶか。
問8. 1台のDBの容量・性能の限界を超えるため、データをキーで複数のサーバに分割して持たせる手法をカタカナで答えてください。