8章：データの更新
2.削除
結論
DELETEはSELECT + 削除処理。
インデックスは「探すために必須」だが、「削除コストは増やす」。
DELETEの本質
DELETEはやっていることとしてはシンプルで、
- 条件に合う行を探す(=SELECT)
- 見つけた行を削除する
つまり
「SELECT + 物理削除」
なので、
WHERE句の性能 = DELETEの性能になる
インデックスの役割
INSERTと大きく異なるポイント
- INSERT → インデックスは邪魔(書き込みコスト増)
- DELETE → インデックスは有利(探索が速い)
理由は単純で、
削除対象を「探す必要がある」から
インデックスなしの場合
インデックスがないとどうなるか
- フルテーブルスキャンで探す
- 削除自体は速い
- ただ、「探す」時間が遅い
結果：全体として遅い
インデックスありの場合
- 条件に合う行を高速に特定できる
- ただし削除時に
- インデックスエントリ削除
- ツリーのバランス維持
が発生する
結果：削除コストは増えるが、それ以上に探索が速い
例外：大量削除
大量に削除する場合は話が変わる
- ほぼ全件削除に近い
- インデックスで絞る意味がない
この場合は、
インデックスなしでもOK(むしろ有利な場合あり)
TRUNCATEとの違い
WHEREなしDELETEの代償(例：PostgreSQL)
- 実際には削除しない
- 「削除フラグ」を立てるだけ
- 実体削除は後で(VACUUM)
この場合
- DELETEは軽い
- インデックス数の盈虚を受けにくい
INSERTとの対比
| 操作 | インデックスの役割 |
|---|---|
| INSERT | 邪魔(書き込みコスト増) |
| DELETE | 必須(探索高速化) |
まとめ
- DELETEは「探してから消す」
- インデックスは探索のために重要
- ただし削除コストは増える
- 大量削除は別戦略(TRUNCATEなど)
- DBの実装(MVCC)で挙動は変わる
ポイント：DELETEはインデックスで速くなり、INSERTはインデックスで遅くなる。