MySQL のインデックス設計原則と一般的なインデックスの違いについて簡単に説明します。

以下のエディターでは、mysqlのインデックス設計原則と一般的なインデックス間の違いについて簡単に説明します。編集者はこれがとても良いものだと思ったので、皆さんの参考として今から共有します。エディターに従って見てみましょう。

インデックス定義: ディスク上に保存される別のデータベース構造であり、データ テーブル内のすべてのレコードへの参照ポインターが含まれます。

データベース インデックスの設計原則:

インデックスの使用をより効率的にするには、インデックスを作成するときに、どのフィールドにインデックスを作成するか、どの種類のインデックスを作成するかを考慮する必要があります。

それでは、インデックスの設計原則とは何でしょうか?

1．一意のインデックスを選択します

一意のインデックスの値は一意であり、インデックスを通じて特定のレコードをより迅速に特定できます。

たとえば、生徒テーブルの中学校番号は一意のフィールドです。このフィールドに一意のインデックスを確立すると、特定の学生の情報を迅速に特定できます。
名前を使用する場合、同じ名前が存在する可能性があり、
クエリの速度が遅くなります。

2.並べ替え、グループ化、ユニオン操作

を頻繁に必要とするフィールドのインデックスを作成します。ORDER BY、GROUP BY、DISTINCT、UNION などの操作を頻繁に必要とするフィールドでは、並べ替え操作に多くの時間がかかります。

インデックスを付けると、並べ替え操作を効果的に回避できます。

3.クエリ条件としてよく使用されるフィールドのインデックスを作成します

フィールドがクエリ条件としてよく使用される場合、このフィールドのクエリ速度はテーブル全体のクエリ速度に影響します。したがって、

そのようなフィールドのインデックスを作成すると、テーブル全体のクエリ速度が向上します。

4.インデックスの数を制限する

インデックスの数は、必ずしも多いほど良いとは限りません。各インデックスにはディスク容量が必要になります。インデックスが増えると、より多くのディスク容量が必要になります。

テーブルを変更する際、インデックスを再構築して更新するのは面倒です。インデックスが増えると、テーブルの更新に時間がかかります。

5.少量のデータのインデックスを使用するようにしてください

インデックス値が非常に長い場合、クエリ速度に影響します。たとえば、CHAR (100) 型フィールドの全文検索は、CHAR (10) 型フィールドよりも確実に時間がかかります。

6.プレフィックスを使用してインデックスを作成してください インデックス フィールドの値が非常に長い場合は、値のプレフィックスを使用してインデックスを作成するのが最善です。たとえば、TEXT および BLOG タイプのフィールドの全文検索は時間の無駄です。フィールドの最初の数文字のみを取得する場合、取得速度を向上させることができます。

7．使用されなくなったインデックス、またはめったに使用されないインデックスを削除します

テーブル内のデータが頻繁に更新されたり、データの使用方法が変更された後、元のインデックスの一部が必要なくなる場合があります。データベース管理者は、更新操作に対するインデックスの影響を軽減するために、これらのインデックスを定期的に見つけて削除する必要があります。

8.小さなテーブルにはインデックスを付けるべきではありません。テーブルに多数の列が含まれており、null 以外の値を検索する必要がない場合は、インデックスを作成しないことを検討できます

----------- ------------------ -------------------------------- --------

mysql Index

関連ヒント: 1. レコードをフィルターするためによく使用されるフィールド。

1. 主キーフィールド、システムは主キーのインデックスを自動的に作成します。2. システムは、制約によって外部キーとして定義された外部キーフィールドを自動的に作成します。 ; 4. クエリでテーブルを結合するために使用されるフィールド

5. 並べ替えの基準としてよく使用されるフィールド

2. インデックスはディスク領域を占有し、不要なインデックスを作成すると、無駄。 。

3. インデックスを作成するときは、データがどのように操作されるかを考慮する必要があります。

1. コンテンツはほとんど変更されず、頻繁にクエリされるため、さらにいくつかのインデックスを作成しても問題ありません。2. 頻繁かつ定期的に変更されるテーブルの場合は、必要なインデックスを慎重に作成する必要があります。インデックス ;

4. 主キーと一意キーの違い

1. 主キーとして使用されるドメイン/ドメイン グループは null にすることはできません。ユニークキーも可能です。 2. テーブル内に存在できる主キーは 1 つだけですが、複数の一意のキーが同時に存在できます。

より大きな違いは論理設計にあり、主キーは一般に論理設計におけるレコード識別子として使用されます。これは
主キーを設定する本来の目的でもありますが、一意キーはドメイン/ドメイン グループの一意性を確保するためだけに使用されます。 。

5. 複合インデックスと単一インデックス

複合インデックスは、クエリを実行するときに、クエリの条件としてこれらのフィールドを結合する必要があることがよくあります

ユニークインデックスは主にプライマリを使用します。キー ID のインデックスとストレージ 構造の順序は物理構造と一致しています

例: tbl(a,b) にインデックス IDx を作成します

最初に a でソートされ、a は b でソートされるため、a またはab、

はこのインデックスを使用できますが、b を検索するだけの場合、このインデックスは検索をスキップできる可能性があります。

------------- ----------- ------------------------

インデックスの追加と削除の状況:

1. テーブルの主キーと外部キーにはインデックスが必要です。

2. 他のテーブルに頻繁に接続されるテーブルにはインデックスが必要です。接続フィールドにインデックスを付ける

のフィールド、特に大きなテーブルにインデックスを付ける必要があります

6.フィールドが長すぎる大きなテキスト フィールドであっても、小さなフィールドに基づいて構築する必要があります。

7. 複合インデックスの構築には、代わりに単一フィールド インデックスの使用を検討する必要があります。

A. 複合インデックスのメイン列フィールドを正しく選択します。これは通常、より選択性の高いフィールドです。 B. 複合インデックスの複数のフィールドが AND モードで同時に出現しますか?単一フィールドのクエリはほとんどないか、まったくありませんか?その場合は、複合インデックスを作成できます。それ以外の場合は、単一フィールド インデックスを検討してください。複合インデックスに含まれるフィールドが Where 句に単独で出現することが多い場合は、複数の単一フィールド インデックスに分割します。 D. 複合インデックスの場合 インデックスに 3 つ以上のフィールドが含まれている場合は、その必要性を慎重に検討し、複合フィールドの数を減らすことを検討してください。

E これらのフィールドに単一フィールド インデックスと複合インデックスの両方がある場合、複合インデックスを削除します。

8. 頻繁にデータ操作を実行するテーブルに大量のインデックスを作成しないでください。

インデックスの確立。

一言で言えば、指標の設定は慎重でなければならず、各指標の必要性を慎重に分析し、設定の根拠がなければなりません。インデックスが多すぎたり、インデックスが不十分であったり、間違っていたりすると、パフォーマンスが向上しません。テーブルにインデックスが作成されるたびにストレージのオーバーヘッドが増加し、インデックスによって挿入、削除、更新操作の処理オーバーヘッドも増加します。さらに、単一フィールドのインデックスがある場合、複合インデックスが多すぎると一般に意味がありません。逆に、特に頻繁に更新されるテーブルの場合、データの追加や削除の際のパフォーマンスも低下します。その悪影響はさらに大きくなります。

以上がMySQL のインデックス設計原則と一般的なインデックスの違いについて簡単に説明します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。