複合インデックス

これ.
インデックスを掛けるときに掛ける複数のインデックスは複合インデックスです.
1)オーダーの表示


IDが同一の場合は同一オーダーとなります
2)テンポラリ・テーブルの作成と貼り付け
クイックメソッド->
SELECT INTOㄱを使用
3)複合インデックスの追加


この2セットにインデックスを付けます!
4)索引情報の表示

これでインデックスが正しいことが確認できます
<テストインデックス1>
コアはこのように2つのインデックスを同時に掛けると役に立ちますか?作った部分
だからこれが当てはまるかどうかを見れば

こうやって出てきます.
Control+Lをクリックし、

RID LookUpとIndex Seekが表示されます

Index Seekの予想実行回数から、以下に3つの1を表示します.
簡単に言えばGOODです.
Index Seek Index SCANが表示されます
SCANはIndex Full Scan、つまり全部探しました.
Badです.
<テストインデックス2>

ひとつ作ると指数Seekも出てきますGOOD
<テストインデックス3>

Table Scan->BADはすべてスキャンした.
->インデックスは使用できません
では、なぜ「インデックステスト3」のような問題が発生するのでしょうか.

これはインデックスを作成する順序と関係があります.
OrderIDはまず1番でProductIdです
ORDERIDで検索できますが、ProductIDのみで検索できます
5)索引情報


こうして出てきました.
ツリー構造

	920
856 888 889 890 891 892 

そうです.
データストア順序の表示

Northwindのノートが1の場合、856ページ3番のオプションに印刷してください.

こうして出てきた

まずORDERIDを比較し,次にProductIdを比較する.
ORDERIDは1位、ProductIdは2位だった.
したがって、インデックス(A,B)を使用している場合は、インデックス(A)を使用する必要はありません.
ただし、Bも検索する必要がある場合は、別途->インデックス(B)を打つ必要があります.
6)インデックスは、データの追加、更新、削除を保持する必要があります.
->ヤメに50個のデータを入れる
-> 10248/11 10387/24

このまま.
インデックス情報を再表示し、


こうやって出てきます.

	920
856 888 889 890 891 892 

もともとそうだったのですが、以前はなかった
921が新しく誕生した.

	920
856 [921] 888 889 890 891 892 

そのまま追加しました
したがって、856ページのデータがオーバーフローした場合、次のデータは921に続く形式で貼り付けられる.
結論:使用可能なページスペースがない場合->ページ分割
7)加工テスト


私をこんな風にさせます.

インデックスを作成します.
またBuという人を探しているとき.

これでいいです.

インデックススキャン中です.
なぜ>>
このように加工して使うと、インデックスは利用できません.
Buで始まるものを探したいなら

LIKEを使用するには

それは問題ありません.

8)今日の結論

複合インデックス(A、B)を使用する場合は、順序(A->B順序検索)に注意してください.
インデックスを使用する場合、追加されたデータに十分なページ領域がない場合、SPLIT
鍵を加工するときは注意!