第30回: 本番運用チェックリスト（MySQL版） — リリース前に必ず確認すべき6つの観点
障害の多くは、機能のバグよりも「バックアップが取れていなかった」「スロークエリの監視がなかった」「権限が過剰だった」といった設定漏れや運用の穴から発生します。本番に出す前にチェックリストを持っておくことで、こうした抜け漏れを事前に防ぐことができます。
Category
カテゴリー: データベース
第29回: レプリケーションの基礎 — 単一DB構成の限界に備える読み取り分散設計
単一のMySQLサーバーにすべての読み書きが集中している構成では、サーバー障害時にサービスが完全停止します。また、アクセスが増えるにつれて読み取りクエリの負荷が書き込みを圧迫し、全体のパフォーマンスが低下する問題も起きます。
第28回: スロークエリログの活用 — 「なんとなく遅い」を計測ベースで解決する
本番でパフォーマンス問題が発生したとき、「たぶんこのクエリが重いはず」という勘で対応しても、インデックスを追加したのに改善しない・別のクエリが原因だったという事態になりがちです。
第27回: SQLインジェクション対策 — 文字列連結でSQLを作っていませんか？
“SELECT FROM users WHERE email = ‘” . $email . “‘” のようにPHPで文字列連結してSQLを組み立てると、’ OR ‘1’=’1 といった入力を受けたとき全データが返る脆弱性になります。これがSQLインジェクション攻撃で、OWASP…
第26回: 権限管理の基本（GRANT） — rootを共用し続けると何が起きるか
開発環境の便利さそのままに、本番でも root ユーザーをアプリに使わせているケースがあります。この状態では、SQLインジェクション攻撃を受けた場合やアプリのバグでDROPが実行された場合に、データベース全体が被害を受けるリスクがあります。
第25回: ビューとストアドプロシージャ — 共通SQLをDB側で管理する判断基準
「論理削除を除いた有効ユーザーを取得するSQL」や「集計結果を求めるSQL」が、コントローラー・バッチ・APIエンドポイントにそれぞれコピーされている状態は管理が困難です。1箇所の条件変更が漏れると、データの不整合を引き起こします。
第24回: パーティションの考え方 — 巨大テーブルの運用負荷を設計で下げる
アクセスログや履歴データを1つのテーブルに蓄積し続けると、削除クエリが重くなり、バックアップに時間がかかり、インデックスが肥大化する問題が起きます。DELETE WHERE accessedat < '2024-01-01' を流すだけで数十分かかる、というケースも珍しくありませ...
第23回: 正規化と非正規化の判断 — 「常に正規化」が正解とは限らない理由
「とにかく正規化すれば正しい」と思っていると、複雑なJOINが増えてパフォーマンスが劣化したり、集計クエリが毎回重くなったりする問題に直面します。一方で「非正規化でいいや」と安易に判断すると、データの更新異常や整合性の崩壊を招きます。
第22回: NULL設計とデフォルト値 — 「意味のないNULL」がバグを生む前に
カラムに深く考えずNULLを許可した結果、アプリ側で if ($value !== null) が乱発され、仕様の解釈が人によって異なるトラブルが起きることがあります。「このNULLは未入力なのか、削除済みなのか、不明なのか？」が曖昧なまま設計が進むと、バグの温床になります。
第21回: 文字コードと照合順序 — 文字化けを根本から防ぐ統一戦略
日本語を扱うアプリを作っていると、突然文字化けが発生したり、大文字・小文字の比較が意図通りに動かなかったりする場面があります。原因は多くの場合、文字コードと照合順序の設定が統一されていないことにあります。