章: 第1章: 基礎と環境構築
取得条件が曖昧だと、何が起きるのか？
SELECT * で全件取得してアプリ側でフィルタリング——これは開発初期によくある実装です。しかしデータが10万件・100万件と増えるにつれ、レスポンスが劣化し、不要なデータ転送でメモリも圧迫されます。
SELECTとWHEREを正しく使いこなすことは、パフォーマンスと正確性の両方に直結します。 取得する列と行を絞り込む習慣を、最初から身につけましょう。
よくある落とし穴：AND/OR の優先順位
WHERE A OR B AND C は WHERE A OR (B AND C) と解釈されます。意図と異なる結果が出ることがあるため、複数条件は必ず括弧で明示します。
WHERE 条件の書き方：良い例・悪い例
| ケース | 悪い例 | 良い例 |
| 部分一致 | WHERE name = '%Yu%'（型間違い） |
WHERE name LIKE 'Yu%' |
| 複数条件 | WHERE a = 1 OR b = 2 AND c = 3 |
WHERE a = 1 OR (b = 2 AND c = 3) |
| NULL比較 | WHERE deleted_at = NULL |
WHERE deleted_at IS NULL |
| 列取得 | SELECT *（全列取得） |
SELECT id, name, email（必要列だけ） |
チェックポイント:
LIKE '%keyword%'の前方ワイルドカードはインデックスが効きません。検索性能が重要な場合は、前方一致LIKE 'keyword%'か全文検索（FULLTEXT）を検討しましょう。
実際のコードのサンプル
SELECT id, name, email
FROM users
WHERE name LIKE 'Yu%'
AND created_at >= '2026-01-01';
まとめ & 次のステップ
SELECT *は避け、必要な列だけを明示して取得するAND/ORの複合条件は括弧で意図を明示する- NULLとの比較は
= NULLではなくIS NULL/IS NOT NULLを使う LIKE 'keyword%'（前方一致）はインデックスが効くが、LIKE '%keyword%'（前方ワイルドカード）は効かない
次回は 「ORDER BYとLIMITで一覧最適化」 を学びます。表示順と件数制御を正しく設計して、一覧APIの品質を上げる方法を確認します。
