ググると、「やたらインデックスだらけになってしまう」という記事が多く見受けられます。しながらパフォーマンスを計測し、インデックスが効くのはどういうときか体験しました。いつものように、受講者の方が使っているRDBMSを調査してスタートです。優子インデックス設計のおさらいまずはインデックスをサラサラと復習します。するときが違うクラスタ索引はデフォルトはプライマリーキーに紐づくプライマリーキーではない値でもOKクラスタ索引はテーブルあたり1つクラスタ索引はテーブルの値を小さい順に並べるので、INSERT時に並び替えの一手間が入るランダムな値が格納されている場合は、クラスタ索引を構成し直すので、時間がかかる夜間バッチで一括INSERTするときには、索引を削除してから処理することが多いいろいろなインデックスRDBMSによって採用されている索引の種類が違うのですが、主な索引の種類を紹介いただきました。しないとアプライされないので、注意が必要です。続く限り、索引でテーブルを作らない遅い。待ちを発生させないナント。演習するここからは実際にどういう検索ならインデックスが使われるのか、実際SQLを実行して試してみます。すると実行計画しか出ないので実行しましょう色々実験してみる林さんからSQL文を紹介してもらい、予想してから、実際に実行してみます。case1インデックスが実行されました。索引を使うことがあるやってみると不思議なもので、どういう値の持ち方をしているとインデックスが効くのか、頭の理解と感覚が一致するようになってきます。この2つのSQLを索引を付けて早くしたい。早くしたければ、索引を新しく作る試行錯誤2とやっていくと、SQL毎にインデックスを作ってしまいがち。結果、バックアップに時間がかかるバックアップのときに、インデックス毎にテーブルを作ってしまうため、容量が増えるでいっぱい作ったインデックスを削除しようとすると、すでに何らかで使われてしまっているため、そのSQLが遅くなってしまうなのでインデックスを一度作ってしまうと削除するのが難しくなってしまう実際にインデックスが増えてしまうことを体験して、このコースは終了しました。まとめあやふやなまま使ってしまうことの多いインデックスについて、色々なインデックスの種類を知った上で、実際にSQLで実験し、どんなときに使えるのか、体感しました。頭では分かっているつもりでも、実際予想しながらやることで、あ、これはアカンやつ、というのがわかるようになりました。「インデックスショットガン」とも呼ばれる、インデックスが増えてしまう問題をやってみて、これまた判断が難しいことも分かりました。銀の弾丸は無いものなんですね。