プログラミングマガジン

プログラミングを中心にIT技術をできるだけわかりやすくまとめます。

  • ホーム
  • データベース
  • 【データベース】インデックスが効かないケース
 
 
     
  • サーバー言語  
    • Python
    • Ruby
    • PHP
    • SQL
  •  
  • インフラ  
       
    • AWS
    •  
    • 基本
    • Git
  • Web
       
    • Web開発
    • JavaScript
    • Vue.js
    • React
  •  
  • 設計  
       
    • 実装設計
    • DB設計
  • 問い合わせ
  

【データベース】インデックスが効かないケース

09.26

  • miyabisan2
  • コメントを書く

この記事は2分で読めます

検索結果が多い

検索結果がテーブル全体の20%未満(実務では10%未満を目標にすると良いです。)、正直選択率が10%を超えていた場合はインデックススキャンよりもフルスキャンの方が望ましいでしょう。

全体の件数が少ない

数万〜数十マン行が目安になります。1000行程度のテーブルであればindexよりもテーブルスキャンが効率的です。

条件にその列を使ってない。

これも当たり前ですね。これだとインデックスが使われません。

1
SELECT * FROM users WHERE num*10 > 100;

このように修正すると使われます。

1
SELECT * FROM users WHERE num > 100/10;

LIKE検索(あいまい検索)は前方一致しか効かない

1
SELECT * FROM users WHERE name LIKE '%田中%';

カラムnameにインデックスを適用した場合には、前方一致(上記例で言えば「田中%」)のみでしか効きません。中間一致(「%田中%」)や後方一致(「%田中」)では効かないので注意が必要です。

検索条件にIS NULLを使っている。

1
SELECT * FROM users WHERE name IS NULL;

これもインデックスは効きません。牽引データの中には通常NULLは含まれないのでインデックスは効きません。

関数を使っている場合も効かない。

1
SELECT * FROM users WHERE LENGTH(name) = 5;

これも牽引列に四則演算を使っている場合と同様にインデックスが適用されません。理由としてはインデックスの中に存在する値はあくまでnameであり、LENGTH(name)の計算結果ではないためです。

カーディナリティの低い列に対する検索

カーディナリティとは?

「列に格納されるデータの値にどれくらいの種類があるのか?」のこと。

つまり、種類が少なく重複が多い列の場合はインデックスは効かないです。

あいまい検索

前方一致と完全一致しか効きません。

統計情報と実際のテーブルで乖離がある場合

統計情報とは?

定期的にテーブルから一定数のサンプリングを行いそれを元に作られる情報のことです。

ただ、以下の場合に「実際のテーブルのデータ分布と乖離した統計情報」が作られる場合もあります。

サンプリングの前に大量データ更新が行われた場合(バッチで大量にinsert、updateした場合など)

サンプリングで偏ったデータを収集した場合

このような場合は、統計情報の更新を行うか、利用する統計情報を固定する方法(ヒント句)があります。

スポンサーリンク
  • 2021 09.26
  • miyabisan2
  • コメントを書く
  • データベース
  • Tweets Twitter
  • このエントリーをはてなブックマークに追加
  • LINEで送る

関連記事

  1. 2018 04.25

    【データベース設計】採番について

  2. 2021 10.10

    【データベース】「JSON型」について

  3. 2018 04.26

    【データベース】「A5:SQL Mk-2」を使ってみる。(Oracleの接続設定等)

  4. 2021 08.01

    【データベース設計】テーブル設計の指針、アンチパターン

  5. 2018 04.24

    【データベース設計】ビューの基本

  6. 2021 11.23

    【Redis】データ型の種類と用途、ユースケース(キャッシュ)

  • コメント ( 0 )
  • トラックバック ( 0 )
  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

返信をキャンセルする。

【SQL】「JOIN」と「パフォーマンス」について

【データベース】テーブル設計:「削除フラグの闇」につい…

RETURN TOP

著者プロフィール

エンジニア歴10年で過去に業務系、Webデザイン、インフラ系なども経験あります。現在はWeb系でフロントエンド開発中心です。

詳細なプロフィールはこちら

スポンサーリンク

カテゴリー

  • Android
  • API
  • AWS
  • C++
  • CSS
  • C言語
  • DDD
  • DevOps
  • Django
  • Docker
  • Git
  • GitLab
  • GraphQL
  • Hasura
  • Java
  • JavaScript
  • Kubernetes
  • Laravel
  • linux
  • MySQL
  • Next.js
  • nginx
  • Node.js
  • NoSQL
  • Nuxt.js
  • Oracle
  • PHP
  • Python
  • React
  • Redux
  • Rspec
  • Ruby
  • Ruby on Rails
  • Sass
  • Spring Framework
  • SQL
  • TypeScript
  • Unity
  • Vue.js
  • WebRTC
  • Webサービス開発
  • Webデザイン
  • Web技術
  • インフラ
  • オブジェクト指向
  • システム開発
  • セキュリティ
  • その他
  • データベース
  • デザインパターン
  • テスト
  • ネットワーク
  • プログラミング全般
  • マイクロサービス
  • マイクロソフト系技術
  • マルチメディア
  • リファクタリング
  • 副業
  • 未分類
  • 業務知識
  • 設計
  • 関数型言語
RETURN TOP

Copyright ©  プログラミングマガジン | プライバシーポリシー