INDEXが使われないパターン

スポンサーリンク

たびたび記事を書いているINDEXネタですが、最近また勉強になったことがありますので紹介します。

スポンサーリンク

INDEXが使われないパターン

  • 検索結果の件数が多い
  • そもそもデータの件数が少ない
  • 重複データが多い

検索結果の件数が多い

INDEXは、テーブルスキャン(全スキャン)よりも少ないスキャン数で検索ができる仕組みとなっています。

検索を早くするためのINDEXですが、実はINDEXを貼っていても使われないパターンがあります。

それは検索結果が多い場合です。

例えば1000行のデータがあるテーブルから5件を取り出す場合、テーブルスキャンだと1000スキャンします。

一方でINDEXを使い、3回のスキャンで1行取得できると、5行取り出すには15回(5件×3スキャン)のスキャンでデータの取得が完了します。

この場合は15回のスキャンで検索が完了しており、INDEXが効いています。

では、逆に考えてみましょう。

1000行あるテーブルから999行取り出してみましょう。

テーブルスキャンの場合は999件のデータを取得するために1000回のスキャンをおこないます。

一方INDEXを使うと1行の取得に3回のスキャンが必要ですので、2997回(999件×3スキャン)のスキャンでデータを取得します。

どうでしょうか。検索件数が多いとINDEXが逆に遅くなることがあるのです。

そのため検索結果が多い検索にはINDEXが使われないのです。

INDEXをうまく使うにはテーブル全件数の20%未満を心がけましょう。

そもそもデータの件数が少ない

上記の見出し「検索結果の件数が多い」と関連しますが、データ件数が少ないテーブルに対してもINDEXが使われないことがあります。

マスタテーブルなど50件しかない場合の検索は全件出力することが多いと思います。

その場合も「検索結果の件数が多い」の例同様に、INDEXを使ったスキャンよりもテーブルスキャンの方が早くなるからです。

INDEXが本当に効いてくるのは大体の目安で数万行からです。

重複データが多い

重複データが多すぎるのもINDEXが使われない原因になります。

仕組みはこれまでと一緒です。

1000件のデータのうち900件が男性、100件が女性とします。

この管理方法を性別カラムで1=男性・2=女性とすると、900行ある男性を検索するにはテーブルスキャンの方がINDEXを使うよりも高速になります。

逆に女性を検索する場合はINDEXが効き、高速に検索できるでしょう。

INDEXは奥が深い

運用が長くなりデータが増えることで、これまで表にでなかった問題が顔を出すことがあります。

知れば知るほど深くなるINDEXの仕組みですが、定期的に本や記事で勉強することで新しい気付きがあります。

今後もDBに関する記事は書いていきたいと思います。

タイトルとURLをコピーしました