私はかなり大きなアプリケーションとデータベースを維持していますが、いくつかのストアド プロシージャでデータベースのパフォーマンスが低下していることに気付きました。
パフォーマンスを向上させるために「インデックスを追加する」ことができるといつも聞いています。私は確かに DBA ではありません。インデックスとは何か、インデックスが役立つ理由、インデックスの作成方法も理解していません。
基本的にインデックス101が必要です。
学習できるようにリソースを提供してくれる人はいますか?
私はかなり大きなアプリケーションとデータベースを維持していますが、いくつかのストアド プロシージャでデータベースのパフォーマンスが低下していることに気付きました。
パフォーマンスを向上させるために「インデックスを追加する」ことができるといつも聞いています。私は確かに DBA ではありません。インデックスとは何か、インデックスが役立つ理由、インデックスの作成方法も理解していません。
基本的にインデックス101が必要です。
学習できるようにリソースを提供してくれる人はいますか?
経験則として、結合または where 句で使用するすべてのフィールドにインデックスを配置する必要があります (インデックスを使用する価値があるほど十分に異なる値がフィールドにある場合、可能な値がわずかしかないフィールドは、インデックスの恩恵を受けません。ビットフィールドにインデックスを付けようとするのはなぜ無意味なのか)。
構造が正式に主キーを作成している場合 (主キーなしでテーブルを作成することはありません)、一意のインデックスを持つには主キーが必要であるため、それらは定義上インデックス化されます。外部キーの関係を設定するときにインデックスが自動的に作成されないため、外部キーにインデックスを付ける必要があることを忘れがちです。外部キーの目的は、結合するフィールドを提供することであるため、ほとんどの外部キーはおそらくインデックス化する必要があります。
一度作成されたインデックスは維持する必要があります。データ変更アクティビティが多い場合、断片化してパフォーマンスが低下する可能性があり、更新が必要になります。索引についてオンラインの書籍を参照してください。create index ステートメントの構文もそこにあります。
通常、インデックスを追加すると、データの挿入、更新、および削除に時間がかかりますが、複雑な挿入、更新、および削除での選択と結合が高速化される可能性があります。上記の経験則から始めるのが良いですが、最良のインデックスとは何かという公式はありません。
図書館のカードカタログに似た索引を考えてみてください。インデックスを使用すると、すべてのアイルや本棚を検索する必要がなくなります。代わりに、ID、名前などの一般的に使用されるフィールドから必要なアイテムを見つけることができる場合があります。インデックスを作成すると、データベースは基本的に、テーブル全体をスキャンするのではなく、クエリがヒットできる別のものを作成します. データの小さなサブセットまたは最適化されたデータ セットを検索できるようにすることで、クエリを高速化します。
インデックスは、データベースシステムがデータをすばやく見つけるために使用する方法です。現実世界のアナロジーは本の索引です。著者/出版社が自分の本の索引付けに優れている場合、読者は索引を見るだけで読みたいページに直接移動することが非常に簡単になります。データベースについても同じことが言えます。フィールドにインデックスが作成されている場合、データベースはデータを事前にソートします。データに対して要求が行われると、データベースはインデックスを使用して、データがハードディスク上のどの場所に保存されているかを識別し、そこに直接移動します。インデックスがない場合、データベースは、クエリの基準を満たしているかどうかを確認するために、すべてのレコードを調べる必要があります。
インデックスを見る簡単な方法は、トランプのデッキを考えることです。索引付けされていないデータベースは、シャッフルされたカードのデッキのようなものです。スペードの王様を見つけたい場合は、すべてのカードを1枚ずつ見て見つける必要があります。あなたは幸運で最初のものかもしれませんし、不運で最後のものかもしれません。
インデックスが付けられたデータベースには、デッキ内のすべてのカードがエースからキングの順に並べられており、各スイートは独自の山に置かれています。スペードを含むカードの山の底を見るだけでよいので、スペードの王を探すのはずっと簡単になりました。
これがお役に立てば幸いです。ただし、リレーショナルデータベースシステムではインデックスが必要ですが、インデックスの数が多すぎると、逆効果になる可能性があることに注意してください。ウェブ上には、索引で読むことができるすばらしい記事がたくさんあります。あなたがそれらに飛び込む前に、私はいくつかの読書をすることをお勧めします。
インデックスは基本的に指定された列でデータを並べ替えてからその順序で保存するため、アイテムを見つけたい場合、データベースは個々の行を調べるのではなく、バイナリ検索 (またはその他の最適化された検索方法) を使用して最適化できます。 .
したがって、検索するデータの量が多い場合は、必ずいくつかのインデックスを追加する必要があります。
ほとんどのデータベースには、クエリがどのように機能するかを説明するツール (db2 の場合は db2expln、おそらく sqlserver に似たもの) と、インデックスやその他の最適化を提案するツール (db2 には db2advis、おそらく sqlserver に似たもの) があります。
前に述べたように、クラスター化インデックスと複数の非クラスター化インデックスを持つことができます。SQL 2005では、非クラスター化インデックスに列を追加することもできます。これにより、一般的に取得されるいくつかの列がインデックスに含まれているが、キーの一部ではない場合にパフォーマンスが向上し、テーブルへの移動が完全になくなります。
SQL Serverデータベースが実行していることを判断するための一番のツールは、プロファイラーです。ワークロード全体のプロファイルを作成してから、推奨されるインデックスを確認できます。また、実行プランを調べて、インデックスがどのような影響を与えるかを確認することもできます。
インデックスが多すぎるという問題は、データベースへの書き込みと、その行のレコードを持つすべてのインデックスを更新する必要があることが原因です。読み取りパフォーマンスが向上している場合は、インデックスが多すぎることが原因ではなく、インデックスが少なすぎるか、不適切すぎることが原因である可能性があります。
インデックスは既存のテーブルに作成され、行をより迅速かつ効率的に検索します。テーブルの1つ以上の列にインデックスを作成することができ、各インデックスには名前が付けられます。ユーザーはインデックスを表示できません。インデックスはクエリを高速化するために使用されるだけです。
基本的に、DBMSは、ソートされた方法で(1つの列からの)データを指すある種のツリー構造を作成します。このようにして、その列のデータを検索するのが簡単になります。
インデックスは、レジスタ内のアイテムのソートされたリストとして説明できます。インデックス内のキーを探すことで、レジスタ内のアイテムの位置をすばやく検索できます。次に、インデックスのキーは、残りのレコードが見つかるレジスタ内の位置へのポインタです。
レジスターには多くのインデックスを設定できますが、インデックスが多いほど、新しいレコードの挿入が遅くなります (各インデックスにも新しいレコードが必要になるため、ソートされた順序で時間がかかります)。
インデックス情報を追加!
クラスタ化インデックスは、テーブル内のレコードの実際の物理レイアウトです。したがって、テーブルごとに 1 つしか持てません。
非クラスター化インデックスは、前述のカード カタログです。確かに、本は特定の順序で並べられていますが、カタログ内のカードを本のサイズ、ページ数、またはアルファベット順の姓で並べることができます。
考慮すべき点 -- 作成するインデックスが多すぎるのはよくある落とし穴です。データが更新されるたびに、DB はそのインデックスをシークして更新し、その新しい行のそのテーブルのすべてのインデックスにレコードを挿入する必要があります。トランザクション システム (考えてみてください: NYSE の株式取引!) では、アプリケーション キラーになる可能性があります。
mssql(およびおそらく他の)の場合、構文は次のようになります。
create index <indexname> on <tablename>(<column1>[,<column2>...])