ラベルのない図書館
「Full Table Scan」
あなたが「夏目漱石の『こころ』」を探しているのに、
図書館の司書は「1冊目から順番に全部確認します」と言いました。
100万冊あるのに。
- リリースから半年後、急に画面の表示が遅くなった
- データベースのCPU使用率が常に100%に近い
- `WHERE`句に使っているカラムにインデックスがあるか誰も知らない
- 「開発環境（データ100件）ではサクサクだった」が口癖だ
データが増えれば増えるほど、システムは死に近づきます。
01. 開発環境の罠
エンジニアのPC（開発環境）に入っているテストデータは、せいぜい数十件〜数百件です。
この量なら、インデックスがなくてもミリ秒単位で検索が終わります。
しかし、本番環境でユーザー数が増え、ログが蓄積され、データが100万件を超えた時、悲劇は起きます。
インデックスのない検索クエリは、データベース全体を端から端まで読み込む「Full Table Scan」を引き起こし、サーバーを停止させます。
100万件なら致命傷。
02. EXPLAINの習慣
SQLを書くときは、必ず実行計画（Execution Plan）を確認する習慣をつけましょう。
MySQLなら `EXPLAIN SELECT ...` を実行し、`type` 列に `ALL` と出ていたら、それは「危険信号」です。
適切にインデックスを貼るだけで、30秒かかっていた処理が0.01秒になることも珍しくありません。
03. 複合インデックスの妙
単にインデックスを貼ればいいわけではありません。
`WHERE category_id = 1 AND status = 'active'` のように複数の条件で絞り込むなら、
それぞれのカラムに単独のインデックスを貼るよりも、「複合インデックス」の方が効果的です。
DBチューニングは、アプリケーションの高速化において最もコスパの良い投資です。