データベース（アプリ開発者として）

インデックスは、本の索引のように、列の値から行の場所をすぐ探せるようにする仕組みです（多くは B-Tree）。インデックスがないと、DB は表を最初から最後まで読むフルスキャンをします。行が少ないうちは気づきませんが、数十万行を超えると急に遅くなります。

複合インデックスの順番

複数の列をまとめたインデックスは、左の列から順にしか使えません（電話帳が「姓→名」の順で並んでいて、名だけでは引けないのと同じ）。

CREATE INDEX idx_orders_user_created ON orders (user_id, created_at);

-- 使える
WHERE user_id = 42
WHERE user_id = 42 ORDER BY created_at DESC LIMIT 20
-- 使えない（先頭の user_id がない）
WHERE created_at >= '2026-11-01'

• 等号で絞る列を先、範囲（>・BETWEEN）や並べ替えに使う列を後にする。
• 絞り込みの効く（値の種類が多い）列が向いている。is_deleted のような2値だけの列は単独では効きにくい。
• 列に関数をかける（WHERE DATE(created_at) = …）、前方以外の LIKE '%abc'、型の違う比較はインデックスが使われにくい。
• インデックスは書き込みを遅くし容量も使うので、使っていないものは消す。

実際にインデックスが使われているかは、次のトピックの EXPLAIN で確かめます。

SRE の「クエリとインデックスのチューニング」

SQL の前に EXPLAIN を付けると、DB がどう実行するか（実行計画）が見られます。EXPLAIN ANALYZE は実際に実行して時間も出します（更新文では本当に更新されるので注意）。

予想の行数と実際が大きくずれていたら、統計情報が古い可能性があります（ANALYZE で更新）。遅いクエリは、スロークエリログや APM で見つけてから EXPLAIN で調べます。

インデックスと複合インデックス

N+1 問題は、一覧を1回取ったあと、各行の関連データを1件ずつ取りに行くことで、SQL が 1＋N 回発行される問題です。ORM が関連を自動で読んでくれるために起こりやすく、1回 1ms でも 100 件なら 100ms 以上になります。

# Rails の例：投稿 100 件 → 著者の SQL が 100 回
Post.limit(100).each { |p| puts p.user.name }
# SELECT * FROM posts LIMIT 100
# SELECT * FROM users WHERE id = 1
# SELECT * FROM users WHERE id = 2 …（100 回）

検出方法

• ログ：開発環境で SQL のログを出し、同じ形の SQL が並んでいないか見る。
• APM（Datadog・New Relic など）：1リクエストの中の SQL の回数と時間が見え、N+1 を自動で指摘するものもある。
• Bullet（Rails）：N+1 を見つけると警告する。テストで有効にして CI で落とすこともできる。Django なら django-debug-toolbar・nplusone などが使えます。
• テストで「この API の SQL は N 回以下」と数を確かめる。

直し方

Post.includes(:user).limit(100).each { |p| puts p.user.name }  # SQL 2回

1対多を JOIN で取ると行数が掛け算で増えるので、子が多いときは IN でまとめるほうが軽いことがあります。件数だけ欲しいなら、関連を全部読まずに COUNT や集計列を使います。

SRE の「N+1問題」

トランザクションは、複数の SQL を「全部成功するか、全部なかったことにするか」にまとめる仕組みです。在庫を減らして注文を作る、のように途中で止まると困る処理に使います。

BEGIN;
UPDATE stocks SET qty = qty - 1 WHERE item_id = 10;
INSERT INTO orders (item_id, user_id) VALUES (10, 42);
COMMIT;  -- 途中で失敗したら ROLLBACK

分離レベルの違い

同時に動く他のトランザクションの変更が、どこまで見えるかを決めるのが分離レベルです。

分離レベルを上げても、「読んでから書く」処理の正しさは自動では守られません。在庫や残高のような更新は、次のトピックのロックで守ります。

大事なのは、どの分離レベルでも「SELECT で在庫を読んで、アプリで計算して、UPDATE で書く」と、同時に動いた2つが同じ値を読んで両方とも成功してしまう（更新の取りこぼし）ことがある点です。次のロックや条件付きの UPDATE で防ぎます。

-- 楽観ロック：0 行なら、他の人が先に更新した
UPDATE articles SET body = ?, version = version + 1
WHERE id = 7 AND version = 3;

A が行1→行2、B が行2→行1の順でロックを取ると、お互いを待ち続けます。これがデッドロックで、DB は片方を自動で失敗させます（MySQL は Deadlock found、PostgreSQL は deadlock detected）。

• ロックを取る順番をそろえる（ID の小さい順など）。
• トランザクションを短くする。中で外部 API を呼んだり、ユーザーの入力を待ったりしない。
• デッドロックや SERIALIZABLE の失敗は、トランザクション全体を少し待ってからやり直す（回数に上限）。

「同じメールアドレスで2人登録させない」を、アプリで先に SELECT して確かめるだけで済ませると、同時に来た2つのリクエストが両方とも「まだない」と判断して、両方とも INSERT できてしまいます。これはチェックと書き込みの間の競合で、テストでは起きにくく、本番で二重押しやリトライのときに起きます。

一意制約で DB に守らせる

ALTER TABLE users ADD CONSTRAINT uq_users_email UNIQUE (email);

一意制約があれば、2つ目の INSERT は DB がエラーにします。アプリはそのエラー（MySQL は 1062、PostgreSQL は 23505）を捕まえて、409 や「すでに登録されています」に変えます。事前の SELECT は画面の案内のためだけに使い、正しさは制約に任せます。(user_id, item_id) のような複数列の組み合わせにも張れます。論理削除の行を除きたいときは、PostgreSQL なら部分インデックス（WHERE deleted_at IS NULL）が使えます。

「なければ作る、あれば更新する」を1つの SQL で、競合なく行うのが UPSERT です。

-- PostgreSQL・SQLite
INSERT INTO likes (user_id, post_id, created_at)
VALUES (42, 7, now())
ON CONFLICT (user_id, post_id) DO NOTHING;

INSERT INTO counters (key, n) VALUES ('views', 1)
ON CONFLICT (key) DO UPDATE SET n = counters.n + 1;

-- MySQL・MariaDB
INSERT INTO counters (`key`, n) VALUES ('views', 1)
ON DUPLICATE KEY UPDATE n = n + 1;

• ON CONFLICT には対象の一意制約（列）を指定する。MySQL の ON DUPLICATE KEY は、どの一意キーにぶつかっても発動するので、一意キーが複数ある表では意図しない行を更新することがある。
• MySQL の INSERT IGNORE は重複以外のエラーまで握りつぶすことがあるので避ける。
• 冪等キーの保存や「いいね」のような二重登録を防ぎたい所に向いている。

マイグレーションは、DB の表の形（スキーマ）の変更を、コードとして順番に管理する仕組みです（Rails の migration、Prisma Migrate、Flyway など）。本番では、動いているアプリを止めずに変えるのが難しい所です。

稼働中の ALTER とロック

• 大きな表への ALTER TABLE は、表を作り直したり強いロックを取ったりして、その間の読み書きを止めることがある。
• PostgreSQL では、ALTER がロックを待っている間、後ろに来た普通の SELECT まで待たされて詰まる。SET lock_timeout = '3s' で待ちすぎたら諦めるようにする。インデックスは CREATE INDEX CONCURRENTLY で作る。
• MySQL は多くの変更をオンライン（ALGORITHM=INPLACE・INSTANT）でできるが、できない変更もあり、大きな表では gh-ost・pt-online-schema-change を使う。
• まず本番に近いデータ量の環境で、かかる時間とロックを確かめる。

SRE の「スキーマ変更の進め方」

アプリとスキーマは同時には切り替わらないので、新旧どちらのアプリでも動く状態を挟みます（expand → contract）。

大量の行の更新は、1つの UPDATE ではなく 1000 行ずつなどに分け、間を空けて流します。ロールバックでアプリを戻しても動くように、削除は最後に、別のリリースで行います。

SRE の「Expand / Contract の手順」

DB への接続を張るのは時間がかかり、DB 側も接続ごとにメモリを使います。そこでアプリはコネクションプールに接続を何本か張っておき、使い回します。

プールの大きさは「大きいほど速い」わけではありません。DB の CPU やディスクには限りがあるので、同時に流すクエリを増やしすぎると、かえって全体が遅くなります。

SRE の「接続プール・スレッド数・並列度」

読み取りの多いサービスでは、書き込みを受けるプライマリから、読み取り専用のレプリカにデータを複製し、読み取りをレプリカに分けます。複製は普通は非同期なので、レプリカは少し遅れています。

ORM やフレームワークには、読み書きで接続先を自動で分ける機能があります（Rails の複数 DB の切り替えなど）。どの処理がどちらに行くかを把握しておきます。

SRE の「レプリケーション遅延の原因と対策」