第05回: SELECTとWHERE条件の使い方 — 「欲しいデータだけ」を正確に取り出す
SELECT で全件取得してアプリ側でフィルタリング——これは開発初期によくある実装です。しかしデータが10万件・100万件と増えるにつれ、レスポンスが劣化し、不要なデータ転送でメモリも圧迫されます。
Month
月: 2026年3月
第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 です。
第36回: 本番運用チェックリスト（Laravel版） — リリース前の確認、属人化していませんか？
経験豊富なエンジニアでも、リリース前の確認を頭の中だけで管理していると、プレッシャーや疲労で抜けが発生します。「APPDEBUG=true のまま本番デプロイ」「監視通知先の疎通未確認」——こうしたミスは、チェックリストがあれば防げます。
第35回: 障害対応ランブック作成 — 障害のたびに「どうすればいいか」を考えていませんか？
アラートが飛んできたとき、「まず何を確認すればいいか」「誰に連絡するか」「どこまで判断していいか」——これらが頭の中だけにある状態では、対応者によって復旧時間に大きな差が出ます。
第34回: Queue監視とアラート設計 — 失敗件数だけ見ていて大丈夫ですか？
Queue の失敗件数がゼロでも、処理が遅延していればユーザーへの影響は出ています。メール送信が1時間遅れる、決済処理が詰まっている——こうした「静かな障害」は失敗件数の監視だけでは検出できません。
第33回: 本番DBマイグレーション戦略 — テーブルロックでサービスを止めていませんか？
ALTER TABLE をそのまま実行すると、完了するまでテーブルがロックされます。数分間の書き込み停止が発生し、サービス障害として記録されます。
第32回: ゼロダウンタイムデプロイ基礎 — デプロイのたびにサービスを止めていませんか？
「コードを更新してからマイグレーションを実行する」「マイグレーション後にコードを反映する」——どちらの順番を選ぶかで、デプロイ中の短時間障害が発生するかどうかが変わります。