1. SQL Server インデックスの仕組みと
断片化、
再構築の必要性について
2012/02/14
インフラグループ 大和屋貴仁

2. 細かいお話の前に……
データベースのデータは、
FusionIOなどの物理ディスク
に書き込んで、保存します。

3. Chapter. 1
物理ディスクのデータ格納のおさらい
ざっくりとした説明をします。
概念レベルなので、
詳しい人にしたら、間違ってる箇所も。。。

4. 物理ディスクのデータ格納
物理ディスクにデータを格納する時は、
最初に部屋を確保します。
どーんと、広いフロアから人を探すの
大変ですよね？
↓まず、部屋を確保
●
Aさん→ ●
↑Aさん専用の部屋

5. 物理ディスクのデータ格納
どーんと、広いフロアに部屋を
たくさん作っていきます。
● ←こんな感じで、新しいデータを
いれる度に部屋を確保します。

6. 物理ディスクのデータ格納
Aさんが太って、
部屋におさまらない場合は？
●
←はみ出しちゃう！！でも、はみ出したら迷惑。

7. 物理ディスクのデータ格納
Aさんの部屋を
大きくしてあげたら良いよね！
●
↑Aさんの部屋を大きくしてあげれば良い。

8. 物理ディスクのデータ格納
部屋を並べ替えたら、
Aさんの部屋も収納できるけど……
●
←部屋を並べ替えてあげれば、
Aさんの部屋を確保できるけど……
Aさんだけの為に、わざわざ部屋並べ替えるの
手間だよね。

9. 物理ディスクのデータ格納
Aさんを切り刻め！！

10. 物理ディスクのデータ格納
切り刻んだAさんを
あっちこっちにあるAさんの部屋に格納。

11. 物理ディスクのデータ格納
え！？
Aさんが必要！？まじか……。
Aさん切り刻んでるから、まず集めなきゃ。
あっちこちにちらばっているAさんの部屋から
Aさんだった残骸を集めて！

12. 物理ディスクのデータ格納
集めたAさんを
くっつけて、Aさん復活！。
●

13. 物理ディスクのデータ格納
ちなみに、
もっとAさんがでっかくなったり、
タイミングによっては……
Aさんの部屋が増えて、
あっちこっちに散らばって、
集めるのが大変！！

14. 物理ディスクのデータ格納
どれぐらい散らばっているかを示すのが
断片化率
と言います。

15. 物理ディスクのデータ格納
デフラグ
って聞いたことありません？
こんな画面でやったデフラグ→

16. 物理ディスクのデータ格納
デフラグって、
切り刻んだAさんをくっつけて、
1個の部屋を用意してあげること。
●
そう！
面倒だから、やらなかった
部屋の並べ替えですね。

17. Chapter. 2
SQL Serverのインデックスの再構築
ざっくりとした説明をします。
概念レベルなので、
詳しい人にしたら、間違ってる箇所も。。。

18. もう一度言います
データベースのデータは、
FusionIOなどの物理ディスク
に書き込んで、保存します。

19. 物理ディスクのデータ格納
データはディスクに書き込むんだから、
断片化とは無縁ではありません。

20. SQL Serverのインデックス
B-Tree式です。
UserID
UserID UserID
１～１００００ １０００１～
UserID UserID UserID UserID
１～５０００ ５００１～１００００ １０００１～１５０００ １５００１～
UserID UserID UserID
１～１０００ １００１～２０００ ２００１～３０００
UserID UserID UserID
２００１～２１００ ２１０１～２２００ ２２０１～２３００

21. SQL Serverのインデックス
インデックスとディスクが
関係しています。
UserID UserID UserID
１～１０００ １００１～２０００ ２００１～３０００
UserID UserID UserID
２００１～２１００ ２１０１～２２００ ２２０１～２３００
インデックスの下に物理ディスクがあります。

22. SQL Serverのインデックス
で、断片化が進むと……。
ユーザID2001～2100を参照するのに
UserID
２００１～３０００ あっちこちを見ないと、いけなくなる。
UserID UserID UserID
２００１～２１００ ２１０１～２２００ ２２０１～２３００

23. 物理ディスクのデータ格納
データベースの中で、
断片化したデータを整理整頓するのが
インデックスの再構築です。
物理ディスク上に散らばっているデータを
整理整頓する作業です。

24. インデックスの再構築は
物理ディスク上に散らばっているデータを
物理的に整理整頓する作業です。
物理的に並べ替えているので、
途中でキャンセルすると、
元に戻します。
掃除をはじめて20分たったときに、
キャンセルすると
掃除をやめるのではなく、
掃除を始める前の状態にもどします。
キャンセルすると20分とは言いませんが、
案外時間かかることもあります。

25. テーブルが断片化すると？
• データを参照するのに、
CPU負荷が増えます。
Disk I/Oが増えます。
参照時間が増えます。
• データを更新するのに
Diskスペースを確保し、
データを切り刻むので、
CPU負荷が増えます。
Disk I/Oが増えます。
更新時間が増えます。

26. データの断片化は……
• データの更新、削除をしていけば
必ず断片化します。
• データ量が増えれば、増えるほど、
断片化によるオーバヘッドが増えます。

27. インデックスの再構築は
• 断片化率が高いほど、再構築に時間が
かかります。
• データ量が多いほど、再構築に時間が
かかります。

28. ご利用は計画的に。
DB性能に問題が無い段階でも、
定期的に、
断片化率の高いテーブルのインデックスを
再構築しておくことで、
トータルでのメンテ時間は短縮できます。

29. IndexView
ツールの準備中。
再構築が必要なインデックスの選定、
再構築時の進捗確認
などが、
しやすいようにツールを作り始めてます。
http://sqlazure.jp/r/sql-server/260/