SQL：INDEXが効かない理由 – LIKE検索・関数使用・暗黙的変換に注意

2026年1月11日

URLをコピーしました！

SQLをチューニングする際、「INDEXを作成したのに処理が遅い」「想定通りにINDEXが使われていない」と感じた経験は多いのではないでしょうか。
この問題は、単純にINDEXが不足しているのではなく、SQLの書き方そのものが原因であるケースが非常に多く見られます。

本記事では、INDEXが効かなくなる代表的な原因として、LIKE検索、関数の使用、暗黙的な型変換の3点に焦点を当て、なぜINDEXが使われなくなるのか、どのように書き換えるべきかを具体例とともに解説します。

INDEXが使われる基本条件

まず前提として、INDEXは「WHERE句で指定した条件をもとに、対象行を素早く絞り込む」ための仕組みです。
データベースは、INDEXを使うことで全件走査（フルスキャン）を回避し、必要な行だけを効率良く取得します。

しかし、以下のような場合にはINDEXの利用が難しくなります。

・列に対して加工や変換が行われている
・検索条件がINDEXの並び順と一致していない
・比較対象のデータ型が一致していない

これらは一見些細な違いに見えますが、実行計画に大きな影響を与えます。

LIKE検索でINDEXが効かない典型例

LIKE検索は文字列検索で頻繁に使用されますが、書き方によってはINDEXがまったく利用されません。

前方一致・中間一致・後方一致の違い

次のようなSQLを比較してみます。

WHERE name LIKE 'ABC%'

1	WHERE name LIKE 'ABC%'

このような前方一致検索は、INDEXが利用される可能性があります。
理由は、検索条件の先頭が固定されており、INDEXの並び順を活用できるためです。

一方で、以下のような書き方は注意が必要です。

WHERE name LIKE '%ABC'
WHERE name LIKE '%ABC%'

1 2	WHERE name LIKE '%ABC' WHERE name LIKE '%ABC%'

これらは後方一致や中間一致となり、INDEXは基本的に使用されません。
先頭がワイルドカード（%）の場合、どの値から検索を開始すべきか判断できないため、全件走査が選択されます。

対策の考え方

・前方一致で検索できる設計に変更する
・検索用に別の列を用意する
・全文検索インデックスなど、用途に合った仕組みを利用する

LIKE検索を多用する設計では、最初からINDEXが使えないケースがあることを前提に検討する必要があります。

WHERE句で関数を使用するとINDEXは使われない

INDEXが効かない原因として非常に多いのが、列に対して関数を適用しているケースです。

典型的な例

WHERE TO_CHAR(created_at, 'YYYYMMDD') = '20260101'

1	WHERE TO_CHAR(created_at, 'YYYYMMDD') = '20260101'

このSQLでは、created_at列に関数が適用されています。
その結果、データベースはINDEX上の値をそのまま利用できず、全行に対して関数を評価する必要が生じます。

INDEXを効かせる書き方

次のように条件を変更すると、INDEXが利用される可能性が高まります。

WHERE created_at >= DATE '2026-01-01'
  AND created_at <  DATE '2026-01-02'

1 2	WHERE created_at >= DATE '2026-01-01' AND created_at < DATE '2026-01-02'

列側を加工せず、比較値側を調整することが重要です。

よくある関数使用例

・TO_CHAR
・SUBSTR
・UPPER / LOWER
・TRUNC

これらをWHERE句で使用する場合は、INDEXが効かなくなる可能性を常に意識する必要があります。

暗黙的な型変換によるINDEX無効化

暗黙的変換は、SQL上ではエラーにならないため見落とされがちですが、パフォーマンス面では非常に危険です。

数値列と文字列の比較

WHERE user_id = '100'

1	WHERE user_id = '100'

user_idが数値型の場合、データベースは内部で暗黙的な型変換を行います。
多くのDBでは、列側が変換対象となるため、結果としてINDEXが使われません。

日付列との文字列比較

WHERE created_at = '2026-01-01'

1	WHERE created_at = '2026-01-01'

このような比較も暗黙的変換が発生します。
見た目は正しくても、実行計画上はフルスキャンになる可能性があります。

明示的に型を合わせる

WHERE user_id = 100

1	WHERE user_id = 100

WHERE created_at = DATE '2026-01-01'

1	WHERE created_at = DATE '2026-01-01'

比較するデータ型を明示的に合わせることで、INDEXが正しく利用されるようになります。

実行計画で必ず確認する

INDEXが使われているかどうかは、実行計画を確認しなければ判断できません。
「INDEXがある＝使われる」と思い込むのは非常に危険です。

実行計画を見ることで、以下を確認できます。

・INDEX SCAN か TABLE SCAN か
・想定外のフルスキャンが発生していないか
・条件の書き方が最適か

SQLのチューニングでは、INDEXが使われているかどうかを判断するために、実行計画の確認が欠かせません。
実行計画（EXPLAIN PLAN）の基本的な読み方や、処理が遅くなる原因となるボトルネックの見つけ方については、以下の記事で詳しく解説しています。

SQL：実行計画（EXPLAIN PLAN）の読み方とボトルネックの見つけ方

よくある質問（Q & A）

INDEXがあるのに必ずフルスキャンになるのはなぜですか？: LIKE検索の書き方、列への関数適用、暗黙的な型変換などにより、INDEXが利用できない状態になっている可能性があります。
LIKE検索は必ずINDEXが使えないのですか？: 前方一致（’文字列%’）であれば、INDEXが使われる可能性があります。先頭に%がある場合は基本的に使われません。
関数を使うと必ずINDEXは無効になりますか？: 列側に関数を適用した場合は無効になるケースが多いです。条件値側を加工する形に書き換えることで回避できます。
暗黙的変換はエラーにならないので問題ないのでは？: 動作上は問題ありませんが、INDEXが効かなくなり、パフォーマンス低下の原因になります。
実行計画は毎回確認すべきですか？: はい。特に本番環境で使用するSQLは、必ず実行計画を確認することをおすすめします。