SQLの性能チューニングやってみた。5つのポイント（MySQL編）

SQLが遅い…その悩み、サクッと解決しよう
まずは結論：5つのポイントを押さえれば速くなる
SQLチューニングの具体的なアプローチ
まとめ：SQLを見直してシステムを速くしよう

SQLが遅い…その悩み、サクッと解決しよう

システムが本番稼働したとたん、画面が重い・バッチが終わらない・顧客から「遅い」と言われる…。そんな経験、きっとあるはずだ。実際、SQLチューニングはパフォーマンス改善の即効薬になりやすい。この記事では、MySQLを題材に、現場でよく効く5つのポイントを紹介する。冗談抜きで、これを押さえるだけで「遅い！」が「速い！」に変わる可能性がある。

まずは結論：5つのポイントを押さえれば速くなる

先に答えを言ってしまうと、次の5つを実践すればかなりの改善が期待できる。

適切なインデックス設計：複合インデックス・カバリングインデックスを正しく使う
EXPLAINで実行計画を確認：フルテーブルスキャンを許さない
LIMIT・OFFSETの扱いに注意：巨大なスキップはやめよう
集約・JOINの見直し：冗長な集計や無駄なJOINを排除する
スキーマ設計を改善：正規化・非正規化のバランスを見直す

ひとつずつ具体例を挙げて解説する。

SQLチューニングの具体的なアプローチ

1. 適切なインデックス設計

まずはインデックス。テーブルにインデックスがないのは、図書館で本の背表紙が全部真っ白なのと同じだ。欲しい本を探すのに毎回全冊めくる羽目になる。

-- 悪い例：インデックスなし
SELECT * 
FROM orders
WHERE customer_id = 123
AND order_date >= '2024-01-01';

-- 改善例：複合インデックスを作成
CREATE INDEX idx_orders_cust_date 
ON orders(customer_id, order_date);

ポイントは、WHERE句でよく使うカラムの組み合わせで複合インデックスを作ること。順序も大事だ。MySQLは左側のカラムから順番に使うので、条件で一番絞り込みが効くカラムを先頭に置くと効果的だ。

2. EXPLAINで実行計画を確認

SQLは動くからといって速いとは限らない。実行計画を見ずにチューニングするのは、目隠しして料理するようなものだ。MySQLならEXPLAINをつけるだけで確認できる。

EXPLAIN 
SELECT o.id, c.name
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.status = 'PAID';

typeがALLならフルテーブルスキャン、rowsが異様に多いなら要注意。インデックスを追加するか、クエリを書き直して絞り込みを強化しよう。

3. LIMIT・OFFSETの扱いに注意

ページングでよくやりがちなのが、LIMIT 10000 OFFSET 500000みたいなクエリ。MySQLは真面目なので、50万件目までちゃんと数えてから返す。つまり50万件を無駄に読み捨てている。

-- 悪い例
SELECT * 
FROM logs 
ORDER BY created_at 
LIMIT 1000 OFFSET 500000;

-- 改善例（カーソル方式）
SELECT * 
FROM logs 
WHERE created_at > '2024-09-01 12:00:00'
ORDER BY created_at 
LIMIT 1000;

前回取得した最後のIDや日時を覚えておいて、それ以降を取るようにすれば無駄が減る。

4. 集約・JOINの見直し

「とりあえずJOIN」「とりあえずGROUP BY」は危険だ。不要なJOINや集計はクエリを重くする。

-- 悪い例：サブクエリの重複
SELECT c.name, 
       (SELECT COUNT(*) FROM orders o WHERE o.customer_id = c.id)
FROM customers c;

-- 改善例：JOIN＋GROUP BYでまとめて集計
SELECT c.name, COUNT(o.id) as order_count
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;

サブクエリを減らしてJOINでまとめると、1回のスキャンで済むため効率が良い。