mysql index勉強会外部公開用

© CROOZ,Inc. 1

MySQL INDEX勉強会技術統括本部

鈴木優一

© CROOZ,Inc. 2

本日の内容・ INDEXとはなにか

・種類と構造

・クエリオプティマイザの流れ

・使いどころ

・効率よくインデックスをつかうために

・ EXPLAINのみかた

© CROOZ,Inc. 3

INDEXとはなにか

© CROOZ,Inc. 4

１．INDEXとはなにか

と言われても実感わかないと思うので

インデックスとは検索の際に利用する「索引」です

次の例で考えてみましょう。

© CROOZ,Inc. 5


例）1組のトランプから「スペードの６」を探す

前提）ランダムに並んでいる ⇒ インデックスがない状態

カードを引く回数を最も少なくして、探すにはどのように探しますか？

© CROOZ,Inc. 6


並び順がランダムだと…

おおよそどの辺にあるのかが予測できない

例えば、上から順番に探すことになります

検索回数の最小は1回、最大54回

⇒ 平均で24回の検索が必要です

© CROOZ,Inc. 7


なんとか効率よくならないか？

そこで、

事前に「スート」「ランク」の順で並べ変えておく

© CROOZ,Inc. 8


事前に並べ変えておくと

おおよそどの辺にあるのかが予測できる

例えば、真ん中のカードを一枚引き、検索対象より前かあとかで探していく

⇒ ２分検索という

© CROOZ,Inc. 9


１回目の検索「クラブ」と「ダイヤ」は除外

２回目の検索「ハート」は除外

３回目の検索「スペード」の「7」～「キング」は除外

４回目の検索「スペード」の「1」～「3」は除外

５回目の検索「スペード」の「4」～「5」は除外

６回目の検索で特定

http://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Set_of_playing_cards_52.JPG

© CROOZ,Inc. 10


この例から以下のことが分かります

事前に規則的に並び替えられたものに対する検索ははるかに早い

並び替えなしの場合は最大54回

並び替えありの場合は最大6回

ただし、事前に並び替えできることが前提

© CROOZ,Inc. 11


事前に並び替えできない場合はどうする？

© CROOZ,Inc. 12


何枚目がなにかを事前にメモっておけば良い！スートランク位置

ハート Q 1

スペード 9 2

: : :

ダイヤ 1 40

: : :

スペード 6 45

なぜなら、要求は「カードを引く回数を最も少なくしてスペード6を探すこと」

セコいとかおもうヒトはいるかもしれませんが何もセコいこはしていないです。

前提条件など一切ないから

このメモさえあれば位置を指定して1回引けば済む

© CROOZ,Inc. 13


今回の例を元にメリットとデメリットを考察すると

メリット

・検索回数が少ない最適に作られていれば1回の検索で完了する

デメリット

・事前にインデックスを作る手間がかかる

・並び替えられたら使い物にならない

© CROOZ,Inc. 14

もう少しシステム寄りに考えると…

© CROOZ,Inc. 15

１．INDEXとはなにか（システム寄りに）

今回の例 select スート, ランク from トランプ where スート = ‘スペード’ AND ランク = ‘6’;

このクエリを最も効率よく実行するためにはどのようにしたらよいか？

© CROOZ,Inc. 16


インデックスを使用しない場合

テーブルをシーケンシャルアクセスで検索する

⇒検索回数はレコード数に比例

インデックスを使用する場合

インデックスから開始位置を特定し、格納先を直接指定して検索する

⇒検索回数はレコード数に比例しない

だからINDEXを使ったほうが効率が良い

© CROOZ,Inc. 17


メリット

・検索回数が少ない最適に作られていれば1回の検索で完了する

デメリット

・更新時に時間がかかる更新の際に再度並び変えなければならないから

・INDEX生成時に時間がかかる事前に並び替えないとならないから

© CROOZ,Inc. 18

種類と構造

© CROOZ,Inc. 19

２．種類と構造

RDBMSで主に使われれるINDEXはB+Tree アルゴリズムで実装されている

補足：RDBMSとは

MySQLのようなデータ構造を2次元のテーブルとテーブルどおしの関係性で表現する仕組みを持ったデータベースアプリケーションのことを言います

© CROOZ,Inc. 20


超簡単に言うと２分検索アルゴリズムの進化版

B+Treeとは

⇒２分検索については8ページを見てください

ルートブロック

ブランチブロック

リーフブロック

1000

500 1500

1:位置：

499:位置

500 :位置：

999 :位置

1000 :位置：

1499 :位置

1500 :位置：

1999 :位置

例 999を検索したい

この位置を指定して

テーブルを検索する

© CROOZ,Inc. 21


MySQLのINDEXは主に以下のものがあります B+Treeアルゴリズムに基づくもの

クラスタインデックス

主キーおよびユニークキーに対し作成されるインデックス

セカンダリインデックス

ユニークでない列に対し作成されるインデックス

上記以外にN-gramに基づくものがありますがここでは割愛します

© CROOZ,Inc. 22

２．１クラスタインデックスの特徴

メリット

・検索が早い特に主キーに対する検索が早い

デメリット

・インデックスサイズが大きい

・条件によってセカンダリインデックスより遅い

なぜかを知るためにクラスタインデックスの仕組みを見てみましょう

© CROOZ,Inc. 23


ルートブロック

ブランチブロック

リーフブロック

1000

500 1500

1:データ：

499:データ

500 :データ：

999 :データ

1000 :データ：

1499 :データ

1500 :データ：

1999 :データ

特徴① リーフブロックにデータが直接格納されている

特徴② データがソートされているため隣接したINDEXが同じリーフブロックに存在する

© CROOZ,Inc. 24


特徴① リーフブロックにデータが直接格納されている

特徴② データがソートされているため隣接したINDEXが同じリーフブロックに存在する

ここから分かること

・主キーに対する検索が早い

何故なら、INDEX内にデータを持っていてテーブルを見なくてよいから

・INDEXサイズが大きい

何故なら、必ずソートされているから

・少ない回数で検索できる

© CROOZ,Inc. 25


メリット

・検索が早い特に主キーに対する検索が早い

デメリット

・インデックスサイズが大きい

・条件によってセカンダリインデックスより遅い

だから

© CROOZ,Inc. 26

２．２セカンダリインデックスの特徴

メリット

・場合によって検索が早いあとで説明します…

デメリット

・場合によらない場合は検索が遅い

なぜかを知るためにセカンダリインデックスの仕組みを見てみましょう

© CROOZ,Inc. 27


特徴① クラスタインデックスと組み合わせて利用する

特徴② リーフブロックにはデータではなく、主キーの値を格納する

リーフ

ブロック

ルート

ブロック

ブランチ

ブロック

キー：場所：

キー：1700

500 :データ：

999 :データ

1000 :データ：

1499 :データ

1500 :データ：

1999 :データ

クラスタインデックスセカンダリインデックス

© CROOZ,Inc. 28


見てわかるとおりひと手間多いです

ではどういう場合にメリットは何か？検索条件で参照する列がすべてインデックスに含まれている場合

なぜなら

必要な情報がすべてリーフブロックに含まれている

↓ 検索対象をクラスタインデックスを利用せずに特定可能

↓ 検索回数が減る

© CROOZ,Inc. 29


メリット

・場合によって検索が早い検索列すべてがインデックスに含まれる場合

デメリット

・上記以外は検索が遅い

だから

検索列をすべてインデックスに含め、インデックス内で検索を完結させることをカバリングインデックスと呼びます

© CROOZ,Inc. 30

２．３カバリングインデックス

カバリングインデックスについて以下の2つがあります

複合インデックス

1つのインデックスキーに複数のカラムを含めたもの

インデックスマージ

複数のインデックスキーを組み合わせて結合したもの

© CROOZ,Inc. 31


イメージで見るとこんな感じ

複合インデックス

キー名種別カラム

idx_familiy INDEX First Name

Middle Name

Family Name

インデックスマージ


idx_first INDEX First Name

idx_middle INDEX Middle Name

idx_family INDEX Family Name

事前に作成されるわけではなく、クエリ実行時に生成される

複合インデックスは存在していないが、単一インデックスが検索項目に含まれる場合、インデックスマージが行われています。

© CROOZ,Inc. 32


ただし、

クエリ実行時に複数のインデックスを読み込んでから結合するため、効率が良くない。

可能な限り複合インデックスを利用すべき

© CROOZ,Inc. 33

今まではINDEXとは何か種類と仕組みについて見てきました。

今後はインデックスがどのように利用させるかを見ていきましょう

© CROOZ,Inc. 34

３． SQLが実行される流れ

皆さんはアプリケーションから発行されたSQLがデータベースサーバ内でどのように処理されているか考えたことはありますか？

© CROOZ,Inc. 35


大まかには以下の作業を行っています

アプリケーション

PARSE

テーブルのチェック

構文チェック

SQL書き換え

実行計画作成

実行計画をキャッシュ

SQL

実行

EXECUTE

データ

取り出し

FETCH

© CROOZ,Inc. 36


よくDBをただのデータ格納場所だと思っている人がいるかと思いますが、実はいろいろ複雑なことをしています

特にPARSEのなかのSQLの書き換え、実行計画作成の部分の処理のことを「SQL最適化」といいDBMS製品のパフォーマンスを大きく左右する部分です。

そして、SQL最適化を行うプログラムを「クエリオプティマイザ」といいます。

この「クエリオプティマイザ」こそがDBMSの肝となります

© CROOZ,Inc. 37

３．クエリオプティマイザの役割

クエリオプティマイザは、最も早くSQLを実行できるためには内部的にどのように検索するのが良いかを推定します。

例えば…

・どのINDEXを使うか

・抽出と結合をどちらが先にやったほうが早いか

・フルテーブルスキャンを行うべきか

など…

このクエリオプティマイザにより、アプリケーションはどのインデックスを使うかやソートアルゴリズムを考えず SQLだけでデータ操作ができます

© CROOZ,Inc. 38

３．クエリオプティマイザの役割

従って、

単にインデックスを付加してもクエリオプティマイザがインデックスで検索しないほうが実行が早いと判断した場合、インデックスが無視されます

例えば、

・極端にレコードが少ない場合 ⇒インデックスを読むコストより、フルテーブルスキャンの方が早い

・複合インデックスがすべての検索条件を満たさない場合

⇒インデックスマージのコストが極端に多いと判断された場合

単にインデックスを付加したからといって必ず効果が出るとは

思わないでください

© CROOZ,Inc. 39

INDEXの使いどころ

© CROOZ,Inc. 40

４． INDEXの使いどころ

基本は３つだけです。・抽出条件として検索する列に作成する

抽出する列ではなく検索する列に対して作成します

・１つのSQLでは1つのインデックスしか参照できない MySQLの仕様です。だからインデックスマージという仕組みがあります

・クラスタインデックスは早い MySQLに設定するときのインデックスの種類は、PRIMARY、INDEX、UNIQUE、FULLTEXTの4つです

この中でPRIMARY、UNIQUEはクラスタインデックスなので検索が早い

© CROOZ,Inc. 41

４． INDEXの使いどころ

これ以外は、ケースバイケース。経験を積むしか無いです

ある程度の法則性はあるので気をつけるべき箇所を挙げておきます。

© CROOZ,Inc. 42

４． WHERE句での注意点その１

否定及び範囲指定(<など)はインデックスが効きません

ユーザーテーブル

Id 年齢 …

1 17 …

2 21 …

3 19 …

4 25 …

5 18 …

6 22 …

WHERE 年齢 !=17 AND 年齢 !=19

WHERE 年齢>=18 AND 年齢<=22

⇒ WHERE 年齢 IN(18,19,20,21,22)

⇒ WHERE 年齢 =18 OR 年齢 =19 OR 年齢 =20 OR 年齢 =21 OR 年齢 =22

INやWHEREで代用します

© CROOZ,Inc. 43

４． WHERE句での注意点その１

ちなみに私だったら面倒なのでこうします

ユーザーテーブル

Id 年齢大学生 …

1 17 0 …

2 21 1 …

3 19 1 …

4 25 0 …

5 18 1 …

6 22 1 …

WHERE 大学生 = 1

勿論事前に[大学生]列にインデックスを貼っておき、[年齢]更新時にUPDATE します。

※ロジック上多少の誤差は出ます

© CROOZ,Inc. 44

４． WHERE句での注意点その２

すべてのANDにかかっていないINDEXは使用できない

WHERE FirstName = ‘努’ AND MiddleName = ‘-’ OR FirstName = ‘太郎’ AND FamilyName = ‘山田’

⇒ インデックスが貼ってあっても「idx_first」のみしか使用できません

インデックス


idx_first INDEX FirstName

idx_middle INDEX MiddleName

idx_family INDEX FamilyName

© CROOZ,Inc. 45

４． WHERE句での注意点その３

あいまい検索時は前方一致のインデックスが使用可能

WHERE FirstName LIKE ‘努%’ 前方一致

WHERE FirstName LIKE ‘%努’ 後方一致

WHERE FirstName LIKE ‘%努%’ 部分一致

WHERE FirstName LIKE ‘努’ 定数

© CROOZ,Inc. 46

４． WHERE句での注意点その４

複合インデックスの場合、前のキーが範囲検索だと以降のキーのインデックスが効かない場合がある

WHERE FirstName > ‘A’ AND MiddleName = ‘John’ AND FamilyName = ‘Sakai’

⇒ FirstName以降インデックスが使用されない可能性があります

インデックス


Idx_name INDEX FirstName

MiddleName

FamilyName

© CROOZ,Inc. 47

４． ORDER BY句での注意点その１

連続しないキーにはインデックスが使用できない

ORDER BY FirstName , FamilyName

⇒ MiddleNameを含める

インデックス



MiddleName

FamilyName

ORDER BY FirstName , MiddleName , FamilyName

© CROOZ,Inc. 48

４． ORDER BY句での注意点その２

複数のキーがある場合はインデックスが使用できない

ORDER BY FirstName , FamilyName

インデックス


idx_first INDEX FirstName

idx_middle INDEX MiddleName

idx_family INDEX FamilyName ⇒ インデックスが効かないクエリオプティマイザの判断でインデックスマージが行われる場合がある

複合インデックスを利用するのがベター

© CROOZ,Inc. 49

４． ORDER BY句での注意点その３

昇順、降順が混在している場合にはインデックスが使用できない

ORDER BY FirstName DESC , FamilyName ASC

インデックス



MiddleName

FamilyName

また降順の場合、複合インデックスのすべてのキーを降順にしなければならない

© CROOZ,Inc. 50

４． ORDER BY句での注意点その３

GROUP BY列とORDER BY列が異なる場合、インデックスは使用できない

GROUP BY FirstName , FamilyName ORDER BY FirstName

インデックス



MiddleName

FamilyName

この場合、内部的には一度テンポラリテーブルを作成してから再度クエリを発行するという動作をします。 EXPLAIN を実行するとUsing temporaryが表示されます

© CROOZ,Inc. 51

４． HIVING句での注意点

HAVING句はインデックスが効きません

スマートにクエリを書きますが速度が極端に遅くなるので極力使わないようにしましょう

© CROOZ,Inc. 52

４．ソートに注意

クエリの中にはクエリ実行時にソートが発生するものがあります。

ソートが発生するものについてはユニークインデックス以外は効果的に機能しません

具体的には以下のとおりです

・MIN

・MAX

・UNION

・DISTINCT

© CROOZ,Inc. 53

効率よくインデックスを使うために

© CROOZ,Inc. 54

５．効率よくインデックスを使うために

クエリオプティマイザは最も早くクエリを実行できる用に実行計画を立てます。つまり絞り込んだ際にレコード数が最も少なくなるようにインデックスを選択します

このようなインデックスのことを「選択性が高い」インデックスといいます

選択性の高いものの代表は以下のとおりです

・主キー

・ユニークキー

選択性の低いものの代表は以下のとおりです

・フラグ系（特に分散が同じようなものは無意味）

© CROOZ,Inc. 55


具体的には・性別

・削除フラグ

単体でインデックスを付けてもあまり効果がありません

© CROOZ,Inc. 56


また複合インデックスは、選択制が高いカラムから順に列を作成します

インデックス


Idx_name INDEX user_id

item_id

delete_flg

最もレコードを絞れる

次にレコードを絞れる

1か0かしかない

SQLを書くときにも選択制が高い順に書きます

WHERE user_id=15321 AND item_id = 45312 AND delete_flg = 0

© CROOZ,Inc. 57


もう一点注意です WHERE句内の場合、複合インデックスの先頭の列は単体インデックスとしても使用できます

インデックス


Idx_name INDEX user_id

item_id

delete_flg

単体インデックスとしても使用可能

複合インデックス作成時はこの点も考慮に入れて下さい

© CROOZ,Inc. 58


最後にもう一点注意です

クエリオプティマイザは最も早くクエリを実行できる用に実行計画を立てるだけで、実際に最も早くクエリを実行しない場合がります。

例えばEXPLAINで見た際に論理上明らかにインデックスを参照したほうが速いはずなのに、インデックスを利用していないなど…

この場合、FORCE INDEX(インデックス名)で使用するインデックスを強制できます

© CROOZ,Inc. 60

６． EXPLAINについて

EXPLAINとは実行計画と結果を表示する機能

使い方

SQLの実行前に EXPLAINをつける

EXPLAINからわかること

・どのインデックスが使われているか

・どのような結合が行われているか

・ソートが内部的に行われているか

© CROOZ,Inc. 61


EXPLAIN実行時の注意点

絶対本番ではやらない世間様に迷惑はかけないでください

対象テーブルデータをバックアップDBからdevにコピーするして行ってください

クエリキャッシュがあることを意識してください頻繁に実行されるクエリはDBMSにキャッシュされます

RESET QUERY CACHEコマンドを実行してキャッシュをクリアしてください

© CROOZ,Inc. 62


クエリキャッシュとは

アプリケーション

PARSE

テーブルのチェック

構文チェック

SQL書き換え

実行計画作成

実行計画をキャッシュ

SQL

実行

EXECUTE

データ

取り出し

FETCH

よく使うクエリのParse内容をキャッシュすることで2回目以降

のParge過程を省略する機能

© CROOZ,Inc. 66


各列の意味列名意味

id SQLの中でSELECT文をするid

select_type SQLの種類

type 参照先テーブルへのアクセス手段

possible_keys オプティマイザが使用するインデックスの候補として挙げたキーの一覧

key possible_keysの中から実際にオプティマイザが選択した物

ref 検索時にkeyの比較対象となっているカラム。定数の場合はconstと表示される。

rows クエリによって取得が想定される行数。実際に取得された数ではないところに注意が必要。実際やってみると結構違う。

Extra クエリの追加情報。Using filesort、Using temporaryが表示された場合は注意が必要。

注目すべきはtypeとExtra

© CROOZ,Inc. 67


typeの各項目の意味値意味

const PRIMARY KEYまたはUNIQUEインデックスのルックアップによるアクセス。最速。

eq_ref JOINにおいてPRIARY KEYまたはUNIQUE KEYが利用される時のアクセスタイプ。constと似ているがJOINで用いられるところが違う。

ref ユニーク（PRIMARY or UNIQUE）でないインデックスを使って等価検索（WHERE key = value）を行った時に使われるアクセスタイプ。

range インデックスを用いた範囲検索。

index フルインデックススキャン。インデックス全体をスキャンする必要があるのでとても遅い。

ALL フルテーブルスキャン。インデックスがまったく利用されていないことを示す。OLTP系の処理では改善必須

Index及びALLが出ていたらキケン

© CROOZ,Inc. 68


Extraの各項目の意味値意味

Using where WHERE句に検索条件が指定されており、なおかつインデックスを見ただけではWHERE句の条件を全て適用することが出来ない場合に表示される。

Using index クエリがインデックスだけを用いて解決できることを示す。Covering Indexを利用している場合なども表示される。

Using filesort filesort（クイックソート）でソートを行っていることを示す

Using temporary JOINの結果をソートしたり、DISTINCTによる重複の排除を行う場合など、クエリの実行にテンポラリテーブルが必要なことを示す。

Using index for group-by

MIN()/MAX()がGROUP BY句と併用されているとき、クエリがインデックスだけを用いて解決できることを示す。

Range checked for …

JOINにおいてrangeまたはindex_mergeが利用される場合に表示される。

ほかにもある…

Using where、 Using tempraryが出ていたらキケン

© CROOZ,Inc. 69


今回の例でいうと

ユニークではないインデックスで等価検索されている

user_id_worker_typeを

利用しようと選択

ただし絞り込み条件でインデックスではなく

WHEREで検索されている

© CROOZ,Inc. 73

実際にやってみよう

今から行う作業をSQLチューニングといいます。まともにやりだすと、それなりに専門領域なのでインデックスにフォーカスして説明します

以下の流れで実施します

比較用テーブルの作成

チューニング対象データのインポート

EXPLAIN実行

EXPLAINを外して実測

© CROOZ,Inc. 96


４．EXPLAINを外して実測単純にクエリを実行して時間を測っても良いのですが、より現実の利用のされ方に近づけるため今回はjmeterというツールで計測します。

負荷をかけた際のパフォーマンスを計測するツールです。以下の特徴ができます。・HTTP以外にもDB、LDAP、SOAPについても計測できる・複雑なシナリオテストが可能・実際の画面遷移を記録しテスト計画を作成できる

jmeter とは

© CROOZ,Inc. 97


４．EXPLAINを外して実測シミュレーション条件

・スレッド数：５０・ランプアップ間隔：0.1 ・ループ回数：10

⇒ 簡単に言うと、50人のユーザが0.1秒ごとに 10回アクセスしていることとほぼ同じ

以下のパターンについて比較を実施・現状・複合インデックスにdelete_flg追加・インデックスなし（参考用）

© CROOZ,Inc. 108

開発ガイドライン

１テーブルあたりのインデックス数

目的によって異なりますが最大で5つを基準として検討してください。

1インデックスあたりの列数

目的によって異なりますが最大で5つを基準として検討してください。

© CROOZ,Inc. 110

インデックスとは目的のものを早く調べるためのカンニングペーパーのようなもの

検索は早いが、更新は遅い

MySQLではクエリ実行時に1つのインデックスしか利用できない

DBMSは入れものではない。データベースの気持ちになって考えよう！

mysql index勉強会外部公開用

Technology