skillup

技術ブログ

Database

データベースのインデックスについて

投稿日:

今回はデータベースのインデックスに関して。

検索条件を早くする場合、何よりも速度が速くなるのはインデックスを張ることでしょう。

インデックスを張ることは単語を索引順に並べることですので、劇的に速度が向上します。

他にも

  • アプリケーション(プログラム)での変更がなく、エンジニアが意識しなくてよい
  • データ自体には影響を与えない

などのメリットもあります。

デメリットは「索引用の内部データを作成しなければいけないため、更新時に若干時間がかかる」ことかと思いますが、メリットに比べると小さいです。

データベースで使われているインデックスは正確にはB-treeインデックスといわれているものです。

Btreeインデックスに関してはの説明はこちらを参考に。

Btreeインデックスが優れている点としては下記のような点です。

  • すべてのデータに対してだいたい同じ計算量でアクセスできること(長期間の運用では少しずつ崩れていく)
  • データ量nに対し、フルスキャンの計算量はlognであること
  • 長期間の運用による性能劣化が他のインデックスに比べて緩やか
  • データの構造上、統合だけでなく、不等号やBetweenに関しても高速化が利く(逆に否定にはきかない)
  • キーをソートしているため、集約関数、ORDER BY、集合関数に強い

具体的にはインデックスは下記のような場合にはると効果的と言われています。

  • またデータ量nに対して計算量がlognなため、データ量が少ないもの(目安として1万以下のレコード)には効果がない
  • カーディナリティの高いもの(データの種類が多いもの。例:顧客番号。逆にカーディナリティが低いものは性別。2種類しかないため。)
  • SQLで検索条件として使われている

逆にインデックスの効果がないものとしては下記のようなケースです。

インデックス列に対して算術演算を行うとき

インデックス列に対してSQL関数を使うとき

インデックス列に対してIS NULLを使うとき

インデックス列に対して否定形を使うとき

インデックス列に対してORを用いているとき

この場合INを使うほうがインデックスの効果はでます。

後方一致、中間一致のlike

前方一致のみが有効です。

暗黙の型変換

数値⇔文字や文字⇔日付を行った場合、エラーにはなりませんが、インデックスを使用することができません。

-Database
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

HAVING句について

本日はHAVINGについて。 かろうじて用法はしっており、たまに使うこともありますが、あまりしっかり理解しているとはいえない状況ですので、掘り下げてみようと思います。 WHEREとは違い、抽出した結果 …

no image

アンチパターン データ分身の術+DBの不要な連携+バージョンアップ未テスト

今回のアンチパターンは主にデータ設計に関する部分。 Contents1 同一データの使用1.1 デメリット1.2 対策2 DBの不要な連携2.1 デメリット2.2 対策3 サーバーの移行やバージョンア …

no image

リレーションを含んだテーブルでの副問い合わせ

本日はSQLネタです。 下記のようなテーブル構成があったときとします。 注文ヘッダと注文詳細は(1:N)とします。 ここで、product_id=5を含んだ注文ヘッダーレコードを取り出したいとします。 …

no image

アンチパターン トランザクションスコープ+大量データのリアルタイム集計+接続が詰まる

本日は主にインフラの設計的なことに関して。 Contents1 トランザクションスコープの設定1.1 デメリット1.2 対策2 大量データのリアルタイム集計2.1 デメリット2.2 対策3 詰まると接 …

no image

MySQLのマイグレーション(workbench使用)

以前cakePHPにてマイグレーションの手法を紹介したのですが、当然PHP以外をつかっていたり、PHPでもcakeを使っていなければこの方法は通用しません。 何か、汎用的にデータベースの構造の差分がチ …