第10回: サブクエリとCTEの基本 — 複雑なSQLを「読める」形に分解する
サブクエリを多重にネストしたSQLは、どこが何を返しているのか追いにくく、バグの原因も特定しづらくなります。3段ネストのサブクエリは、書いた本人でも翌週には読めないことがあります。
Category
カテゴリー: データベース
第09回: HAVING句の使い所 — WHEREで書けないなら、HAVINGの出番
WHERE postcount >= 10 と書きたくなりますが、postcount は集計結果なので WHERE の時点ではまだ存在しません。WHERE はグループ化・集計の前に評価されるため、集計後の値を条件にするには別の構文が必要です。
第08回: GROUP BYと集計関数 — アプリ側ループで集計するのはもう終わりにする
全投稿を取得してPHPの配列で count() するコードは、データが増えるほどメモリと処理時間を消費します。1万件のレコードを全件取得してアプリ側で集計するのは、DB本来の仕事をわざわざ横取りしている状態です。
第07回: JOINの基本（INNER/LEFT） — ループで1件ずつ取るのをやめる
投稿一覧を取得した後、各投稿の著者名を取るためにループで SELECT FROM users WHERE id = ? を繰り返す——これがN+1問題の典型例です。100件の投稿があれば101本のSQLが走り、データが増えるほどレスポンスが悪化します。
第06回: ORDER BYとLIMITで一覧最適化 — 「並び順が毎回違う」を今すぐ直す
一覧画面でよくある失敗が「ORDER BYを書かずにLIMITだけ指定する」パターンです。ORDER BYなしのLIMITは、MySQLが内部でどの行を返すかを保証しないため、同じクエリでも実行するたびに結果の順番が変わるという不具合が起きます。さらに、データ量が増えると OFF…
第05回: SELECTとWHERE条件の使い方 — 「欲しいデータだけ」を正確に取り出す
SELECT で全件取得してアプリ側でフィルタリング——これは開発初期によくある実装です。しかしデータが10万件・100万件と増えるにつれ、レスポンスが劣化し、不要なデータ転送でメモリも圧迫されます。
第04回: INSERT/UPDATE/DELETEの基本 — データ操作のミスをゼロにする書き方
UPDATE users SET name = ‘admin’ ——WHERE句を忘れた瞬間、全ユーザーの名前が書き変わります。更新系SQLのミスはデータ欠損に直結し、バックアップからの復元が必要になることも。
第03回: 主キー・外部キーの基本 — データの「つながり」を壊さないために
ユーザーを削除したのに、そのユーザーの投稿が残り続ける。存在しないユーザーIDを持つ注文レコードが生まれる。外部キー制約がないDBは、アプリ側のバグがそのままデータ破損につながります。
第02回: データベースとテーブルの作成 — 最初の定義がすべてを決める
DB設計でよくある失敗は、文字コードを指定せずにテーブルを作り、絵文字が入らなかったり日本語が文字化けしたりすること。あるいはカラムの型を雑に決めて、後から ALTER TABLE で大量データを抱えたまま変更しようとして詰まること。
第01回: MySQLの全体像と学習環境 — 「なぜMySQLを学ぶのか」から始めよう
ほぼすべてのWebサービス——SNS・ECサイト・業務システム——は、裏側にデータベースを持っています。その中で世界シェアトップを争うのが MySQL です。