遅い SQL を、どう調べてどう直しますか

どの SQL から直すか

DB には、決めた時間より遅いクエリを記録する仕組みがあります。監視の道具でも、SQL ごとの回数と時間を見られます。

ここで大事なのは、1 回が 3 秒の SQL より、1 回 50 ミリ秒でも 1 分に何千回も流れる SQL のほうが、DB 全体を重くしていることがある点です。回数と 1 回の時間をかけた全体の時間で並べ、上から手を付けます。1 つの画面で同じ形の SQL が何十回も流れているなら、N+1 問題を疑います。

実行計画を読む

見つけた SQL の頭に EXPLAIN を付けると、DB がどう読むつもりか (実行計画) が出ます。見る所は次の通りです。

• 表を頭から全部読んでいないか (全件の走査)
• 使うと思っていたインデックスが、本当に使われているか
• 読む行の見積もりが、返す行に比べて多すぎないか
• 並べ替えや一時的な表づくりに時間を使っていないか

PostgreSQL の EXPLAIN ANALYZE のように、実際に流して時間を測る指定もあります。これは本当にクエリを実行するので、更新や削除の文に付けるときは気をつけます。

よくある原因と直し方

-- 列に関数をかけると、その列のインデックスが使われにくい
SELECT * FROM orders WHERE DATE(created_at) = '2026-10-01';

-- 列はそのまま、範囲で書く
SELECT id, total FROM orders
WHERE created_at >= '2026-10-01' AND created_at < '2026-10-02';

• 条件の列にインデックスが無い、合っていない 複合インデックスは列の順番が効きます。等しいで絞る列を前に、範囲や並べ替えに使う列を後ろに置くのが基本です
• 列に関数や型の変換をかけている 上の例のように、列をそのままにした書き方に直します
• 深いページを OFFSET で取っている 1 万件目からの 20 件でも、DB は前の 1 万件を読んで捨てます。「前のページの最後の id より後」で取る書き方 (キーセット方式) に変えます
• 要らない列や行まで取っている SELECT * をやめて要る列だけにし、件数を絞ります

本番に近い量で測る

行の少ない手元の DB では、全部読んでも速いので差が出ません。DB は表の大きさや値の偏りを見て計画を選ぶので、量が違うと計画そのものが変わることもあります。本番に近い量と偏りのデータで、直す前と後の実行計画と時間を並べてから出します。

トレードオフ

インデックスは読むのを速くしますが、書き込みのたびに更新されるので、書き込みは遅くなり、場所も取ります。似たインデックスが増えると、DB がどれを使うか迷うこともあります。足すときは、ほかの SQL でも使えるか、もう要らないインデックスは無いかも見ます。大きな表にインデックスを作るときは、読み書きを止めない作り方ができるかを、使う DB の文書で確かめます。

話す例は架空の例で構いません。「一覧の画面が遅く、記録を見ると深いページの OFFSET が原因だったので、id で続きを取る形に変えた」のように、見つけ方、原因、直し方、測った結果を 1 本の話にします。