第20回: バックアップとリストアの基本 — 「バックアップがある」では足りない
「定期バックアップは設定してある」——それだけで安心していませんか？バックアップは取得するだけでなく、実際に復元できることを事前に確認しておかなければ、いざという場面で役に立ちません。この回では mysqldump を使ったバックアップと復元の基本手順を整理します。
Category
カテゴリー: データベース
第19回: デッドロックの見つけ方と対策 — 止まらないシステムを設計で守る
「トランザクションが完了しない」「接続がタイムアウトする」——こうした症状の裏にデッドロックが潜んでいることがあります。デッドロックは完全にゼロにはできませんが、検知の方法と設計上の対策を知っていれば、被害を最小化できます。
第18回: 悲観ロックと楽観ロック — 競合更新を「防ぐ」か「検知」するか
在庫管理・予約システム・残高更新——複数のユーザーが同時に同じデータを書き換えようとする場面では、何も対策しなければ後からの更新が前の更新を上書きしてしまいます。これを防ぐのが「悲観ロック」と「楽観ロック」という2つのアプローチです。
第17回: 分離レベルとロックの考え方 — 同時実行の「幻の不整合」を防ぐ
トランザクション中にほかのトランザクションが更新したデータを読んでしまう——これがダーティリードやファントムリードと呼ばれる問題です。分離レベルを理解することで、同時実行時に「どの程度の一貫性を保証するか」を意図的に設計できるようになります。
第16回: トランザクションの基本 — 複数更新を「全部成功か全部取消」に守る
口座Aから500円を引いた瞬間にエラーが発生し、口座Bへの加算が行われなかった——こんな事態を防ぐのがトランザクションです。複数の更新をひとつの「まとまり」として扱い、全部成功するか、全部なかったことにする仕組みです。
第15回: クエリチューニングの手順 — 計測なき最適化は迷走する
「なんとなく遅そうだからインデックスを足した」——そのインデックスは本当に効いていましたか？感覚だけでクエリを変更すると、改善なのか改悪なのか判断できず、問題が複雑化します。クエリチューニングは「計測→仮説→検証」の順で進めることで、再現性のある改善ができます。
第14回: N+1をSQL側で防ぐ — ループ取得の罠を設計で断ち切る
ユーザー一覧を表示するたびに、各ユーザーの投稿を個別に取得している——そんな実装を見たことはないでしょうか。これがN+1問題です。10件なら10回、1000件なら1001回のクエリが走り、データ量の増加とともに急激にレスポンスが悪化します。
第13回: EXPLAINの読み方 — 勘を捨てて実行計画を読む
体感でクエリを最適化しようとすると、改善なのか改悪なのか判断できません。EXPLAINを使えば、MySQLがどのようにクエリを実行しているかを数値で把握できます。この回ではEXPLAINの読み方を整理し、根拠ある改善ができるようになりましょう。
第12回: 複合インデックスの順序 — 列の並びひとつで速度が激変する
「インデックスを追加したはずなのに、クエリが遅い」——そんな経験はありませんか？実は複合インデックスは、列の順序を間違えるとほとんど機能しません。正しい順序で設計するだけで、クエリが劇的に速くなるケースがあります。この回では複合インデックスの順序の考え方を整理していきます。
第11回: インデックスの基本戦略 — 「なぜ遅いのか」を論理的に説明できますか？
テスト環境では一瞬だったクエリが、本番の数十万件データでは5秒以上かかる。そういう事態に直面したとき、「インデックスを貼ればいいんじゃないか」と感覚で対応するのは危険です。闇雲にインデックスを追加すると、INSERT/UPDATE のたびにインデックスの更新コストが増え、むしろ書…