mysql上級(2)インデックス簡単チュートリアル

Mysql インデックスの簡単なチュートリアル

基本概念

インデックス作成とは、インデックスとして設定したフィールド A の内容を、このフィールドの内容のみを含む独立した間隔 S に保存することを指します。このフィールド A の内容を検索する場合、データ テーブル内で検索するのではなく、この独立した間隔から直接検索されます。これらの修飾フィールドを見つけたら、フィールド A が指す実データ レコードの物理アドレスを読み取り、対応するデータ コンテンツを出力します。インデックスが作成されていないフィールドを探している場合は、データ テーブルから検索されます。データテーブルには無関係なフィールドが多数あるため、データベースプログラムはそれらを省略したり検索したりしません。これらの無関係なフィールドを特定し、レコードに複数回ジャンプするには、ある程度のリソースが必要です。もちろん、設定するインデックスの数が多いほど良いです。インデックスはこの独立区間 S に配置されるため、独立区間 S が大きくなるほど、検索リソースも大きくなります。インデックスが作成されているフィールドが 1 つだけの場合、このフィールドの検索は非常に高速です。

インデックスを作成する目的は、テーブル内のレコードの検索または並べ替えを高速化することです。テーブルのインデックスの設定には代償が伴います。まず、データベースの記憶領域が増加します。次に、データの挿入と変更に時間がかかります (インデックスもそれに応じて変更されるため)。

インデックスの利点は、指定された列をソートし、検索速度を向上させることができることです。

簡単な例:

特定の列のデータは

ID名

12 Xiao Li

10 Xiaolong

5 Xiaoqing

99 Xiaohong

ID列の作成後、インデックスが生成されます. テーブル

id インデックス

5 3

10 2

12 1

99 4

id =10 の場所をクエリする場合、インデックス テーブルが使用されます。 10未満は5だからです。したがって、テーブル スキャン操作は実行されなくなります。メインテーブルの 2 行目に対応する 2 番目のデータを返します。これにより、インデックスが追加されない場合、メイン テーブル全体がスキャンされるため、クエリの速度が向上します。

インデックスの種類、インデックスを作成する必要がある列、およびその他の関連情報については、Baidu で検索する必要があります。ここで説明するのは、いくつかの基本的な概念です。

データベースインデックスの機能、メリット、デメリット

なぜインデックスを作成するのか?これは、インデックスを作成するとシステムのパフォーマンスが大幅に向上する可能性があるためです。

まず、一意のインデックスを作成することで、データベーステーブル内のデータの各行の一意性を保証できます。

2 番目に、データの取得を大幅に高速化できます。これがインデックスを作成する主な理由でもあります。

3 番目に、テーブル間の接続を高速化できます。これは、データの参照整合性を達成する上で特に意味があります。

4 番目に、データの取得にグループ化句と並べ替え句を使用すると、クエリでのグループ化と並べ替えにかかる時間も大幅に短縮できます。

5 番目に、インデックスを使用すると、クエリ プロセス中に最適化非表示機能を使用してシステムのパフォーマンスを向上させることができます。

「インデックスを追加するとたくさんの利点があるのに、テーブル内のすべての列にインデックスを作成しないのはなぜですか?」と疑問に思う人もいるかもしれません。この考えは合理的ですが、一方的でもあります。インデックスには多くの利点がありますが、テーブル内のすべての列にインデックスを追加するのは非常に賢明ではありません。これは、インデックスの追加には多くの欠点があるためです。

まず、インデックスの作成と維持には時間がかかり、データ量が増えるとこの時間も長くなります。

第 2 に、インデックスはデータ テーブルが占有するデータ スペースに加えて、一定量の物理スペースも占有する必要があります。クラスター化インデックスを構築する場合、必要なスペースはさらに大きくなります。

3 番目に、テーブル内のデータを追加、削除、変更する場合、インデックスを動的に維持する必要があるため、データのメンテナンス速度が低下します。

インデックスはデータベーステーブルの特定の列に基づいて構築されます。したがって、インデックスを作成するときは、どの列にインデックスを付けることができ、どの列にインデックスを付けることができないかを慎重に検討する必要があります。一般に、次のような列にインデックスを作成する必要があります。

頻繁に検索される列では、検索を高速化できます。

主キーとして機能する列では、列の一意性を強化し、テーブル内のデータ 配置構造

接続でよく使用される列では、これらの列は主に外部キーとなり、接続を高速化できます

範囲に基づいて検索する必要がある列にインデックスを作成します。インデックスはソートされています

指定された範囲は連続しています。

頻繁にソートが必要な列にインデックスを作成します。インデックスは既にソートされているため、クエリでインデックスのソートを使用してソートクエリ時間を短縮できます。

WHERE 句でよく使用される列にインデックスを作成して高速化します。状態の判断を上げます。

また、インデックスを作成してはいけない列もあります。一般に、インデックスを作成すべきではない列には次のような特徴があります:

まず、クエリでほとんど使用または参照されない列にはインデックスを作成しないでください。これは、これらの列がほとんど使用されないため、インデックスを作成してもしなくてもクエリ速度は向上しないためです。逆に、インデックスの追加により、システムのメンテナンス速度が低下し、必要なスペースが増加します。

第 2 に、データ値が少ない列のインデックスは増加させるべきではありません。これは、クエリ結果ではこれらの列 (人事テーブルの性別列など) の値が非常に少ないため、結果セット内のデータ行がテーブル内のデータ行の大部分を占めるためです。テーブル内で検索する必要があるデータ 行の割合が膨大です。インデックスを増やしても、検索が大幅に高速化されるわけではありません。

第三に、テキスト、イメージ、ビットのデータ型として定義された列にはインデックスを追加しないでください。これは、これらの列のデータ量が非常に大きいか、値が非常に少ないためです。

4番目に、変更パフォーマンスが検索パフォーマンスよりもはるかに大きい場合、インデックスは作成されるべきではありません。修正性能と検索性能は相反するものだからである。インデックスを追加すると、検索パフォーマンスは向上しますが、変更パフォーマンスは低下します。インデックスを減らすと、変更パフォーマンスは向上しますが、検索パフォーマンスは低下します。したがって、変更パフォーマンスが検索パフォーマンスよりもはるかに優れている場合は、インデックスを作成しないでください。

インデックスの作成方法とインデックスの特徴

インデックスの作成方法

インデックスを作成するには、直接インデックスを作成する方法と間接的にインデックスを作成する方法など、さまざまな方法があります。インデックスは、CREATE INDEX ステートメントやインデックス作成ウィザードを使用して直接作成されます。また、インデックスは間接的に作成されます (テーブルに主キー制約または一意キー制約を定義する場合など)。インデックスも作成されます。

どちらの方法でもインデックスを作成できますが、インデックス作成の具体的な内容が異なります。

CREATE INDEX ステートメントを使用するか、インデックス作成ウィザードを使用してインデックスを作成します。これはインデックスを作成する最も基本的な方法であり、ニーズに合わせてインデックスをカスタマイズできます。

この方法でインデックスを作成する場合、インデックスを最適化できるように、データ ページの充実度の指定、並べ替え、統計の並べ替えなど、多くのオプションを使用できます。この方法を使用すると、インデックスのタイプ、一意性、および複合性を指定できます。つまり、クラスター化インデックスまたは非クラスター化インデックスのいずれかを作成でき、1 つまたは 2 つの列にインデックスを作成することもできます。 3 つ以上の列のインデックス。

主キー制約または一意キー制約を定義することで、間接的にインデックスを作成することもできます。主キー制約は、テーブル内のレコードが同じ主キー レコードを持つように制限することでデータの整合性を維持するロジックです。主キー制約を作成すると、システムは一意のクラスター化インデックスを自動的に作成します。

論理的には主キー制約は重要な構造ですが、物理構造的には主キー制約に対応する構造は一意のクラスター化インデックスになります。つまり、物理的な実装では、主キー制約はなく、一意のクラスター化インデックスのみが存在します。

同様に、一意キー制約を作成すると、一意の非クラスター化インデックスであるインデックスも作成されます。したがって、制約を使用してインデックスを作成する場合、インデックスの種類と特性は基本的に決まり、ユーザーによるカスタマイズの余地は少なくなります。

テーブルに主キー制約または一意キー制約を定義するとき、そのテーブルに CREATE INDEX ステートメントを使用して作成された標準インデックスがすでにある場合、主キー制約または一意キー制約によって作成されたインデックスは、以前に作成された標準インデックスを上書きします。 。つまり、主キー制約または一意キー制約によって作成されたインデックスは、CREATE INDEX ステートメントを使用して作成されたインデックスよりも高い優先順位を持ちます。

インデックスの特徴

インデックスにはユニークインデックスと複合インデックスという2つの特徴があります。

一意のインデックスにより、インデックス列内のすべてのデータが一意であり、冗長なデータが含まれていないことが保証されます。テーブルに主キー制約または一意キー制約がすでに設定されている場合、SQL Server はテーブルの作成または変更時に一意のインデックスを自動的に作成します。

ただし、一意性を保証する必要がある場合は、一意のインデックスの代わりに主キー制約または一意キー制約を作成する必要があります。一意のインデックスを作成するときは、次のルールを慎重に考慮する必要があります。 テーブルに主キー制約または一意キー制約を作成するとき、SQL Server は、テーブルに既にデータが含まれている場合は、インデックスの作成時に自動的に一意のインデックスを作成します。 Insert ステートメントを使用してデータを挿入するか、modify ステートメントを使用してデータを変更するたびに、SQL Server はデータの冗長性をチェックします。冗長な値がある場合、SQL Server はステートメントの実行をキャンセルし、エラー メッセージ

を返します。

テーブル内のデータの各行に一意の値があることを確認します。これにより、各エンティティが一意に確認できるようになります。一意性は、エンティティの整合性を保証できる列にのみ作成できます。たとえば、一意のインデックスは作成できません。人は同じ名前を持つことができるため、人事テーブルの名前列に入力します。

複合インデックスは、2 つ以上の列に対して作成されるインデックスです。検索時に、2 つ以上の列がキー値として機能する場合は、これらの列に複合インデックスを作成するのが最善です。複合インデックスを作成するときは、次のルールを考慮する必要があります。 最大 16 列を 1 つの複合インデックスに結合でき、複合インデックスを構成する列の合計長は 900 バイトを超えることはできません。複合列は長すぎてはなりません。

複合インデックスでは、すべての列が同じテーブルに由来する必要があり、複合インデックス内の複数のテーブルに複合列を作成することはできません。そのため、列の順序は非常に重要です。原則として、列は慎重に配置する必要があります。たとえば、列の順序が異なるため、(COL1、COL2) のインデックスは (COL2、COL1) のインデックスと同じではありません。 2 つのインデックスは異なります。

クエリ オプティマイザーで複合インデックスを使用するには、テーブルに複数のキー列がある場合、クエリ ステートメントの WHERE 句で複合インデックスを参照する必要があります。非常に便利です。複合インデックスを使用すると、クエリのパフォーマンスが向上し、テーブル内のクエリの数と作成されるインデックスの数が削減されます。

インデックスの種類

一意でないインデックスは、このインデックス内の値の繰り返しが許可されていることを意味します。一意のインデックスと比較して、このインデックスの値を繰り返すことはできません。

簡単な例は、ID カードのようなものです。データベースに保存されている場合。名前にインデックスを作成すると、同じ名前の人物が存在するため、一意ではないインデックスになります。 ID番号にインデックスを作成すると、番号が重複するので面倒になります。

上記は、mysql 上級 (2) インデックスの簡単なチュートリアルの内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。