Sql serverインデックスの断片化と再構築の必要性について
- 1. SQL Server インデックスの仕組みと 断片化、 再構築の必要性について 2012/02/14 インフラグループ 大和屋貴仁
- 3. Chapter. 1 物理ディスクのデータ格納のおさらい ざっくりとした説明をします。 概念レベルなので、 詳しい人にしたら、間違ってる箇所も。。。
- 4. 物理ディスクのデータ格納 物理ディスクにデータを格納する時は、 最初に部屋を確保します。 どーんと、広いフロアから人を探すの 大変ですよね？ ↓まず、部屋を確保 ● Aさん→ ● ↑Aさん専用の部屋
- 5. 物理ディスクのデータ格納 どーんと、広いフロアに部屋を たくさん作っていきます。 ● ←こんな感じで、新しいデータを いれる度に部屋を確保します。
- 7. 物理ディスクのデータ格納 Aさんの部屋を 大きくしてあげたら良いよね！ ● ↑Aさんの部屋を大きくしてあげれば良い。
- 8. 物理ディスクのデータ格納 部屋を並べ替えたら、 Aさんの部屋も収納できるけど…… ● ←部屋を並べ替えてあげれば、 Aさんの部屋を確保できるけど…… Aさんだけの為に、わざわざ部屋並べ替えるの 手間だよね。
- 11. 物理ディスクのデータ格納 え！？ Aさんが必要！？まじか……。 Aさん切り刻んでるから、まず集めなきゃ。 あっちこちにちらばっているAさんの部屋から Aさんだった残骸を集めて！
- 13. 物理ディスクのデータ格納 ちなみに、 もっとAさんがでっかくなったり、 タイミングによっては…… Aさんの部屋が増えて、 あっちこっちに散らばって、 集めるのが大変！！
- 16. 物理ディスクのデータ格納 デフラグって、 切り刻んだAさんをくっつけて、 1個の部屋を用意してあげること。 ● そう！ 面倒だから、やらなかった 部屋の並べ替えですね。
- 17. Chapter. 2 SQL Serverのインデックスの再構築 ざっくりとした説明をします。 概念レベルなので、 詳しい人にしたら、間違ってる箇所も。。。
- 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 ２００１～２１００ ２１０１～２２００ ２２０１～２３００
- 24. インデックスの再構築は 物理ディスク上に散らばっているデータを 物理的に整理整頓する作業です。 物理的に並べ替えているので、 途中でキャンセルすると、 元に戻します。 掃除をはじめて20分たったときに、 キャンセルすると 掃除をやめるのではなく、 掃除を始める前の状態にもどします。 キャンセルすると20分とは言いませんが、 案外時間かかることもあります。
- 25. テーブルが断片化すると？ • データを参照するのに、 CPU負荷が増えます。 Disk I/Oが増えます。 参照時間が増えます。 • データを更新するのに Diskスペースを確保し、 データを切り刻むので、 CPU負荷が増えます。 Disk I/Oが増えます。 更新時間が増えます。
- 26. データの断片化は…… • データの更新、削除をしていけば 必ず断片化します。 • データ量が増えれば、増えるほど、 断片化によるオーバヘッドが増えます。
- 27. インデックスの再構築は • 断片化率が高いほど、再構築に時間が かかります。 • データ量が多いほど、再構築に時間が かかります。
- 29. IndexView ツールの準備中。 再構築が必要なインデックスの選定、 再構築時の進捗確認 などが、 しやすいようにツールを作り始めてます。 http://sqlazure.jp/r/sql-server/260/