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

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

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

インデックスをより効率的に使用するには、インデックスを作成するときに、どのフィールドにインデックスを作成するか、またどのようなタイプのインデックスを作成するかを考慮する必要があります。
では、インデックス設計の原則は何でしょうか?

1.一意のインデックスを選択

一意のインデックスの値は一意であり、このインデックスを使用してレコードをより迅速に識別できます。
たとえば、学生テーブルの学生 ID は一意のフィールドです。このフィールドに一意のインデックスを作成すると、学生の情報をすぐに特定できます。
フルネームを使用すると、名前が重複する可能性があり、検索が遅くなります。

2.並べ替え、グループ化、結合操作を頻繁に必要とするフィールドにインデックスを作成します。

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

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

フィールドがクエリ条件として頻繁に使用される場合、このフィールドのクエリ速度はテーブル全体のクエリ速度に影響します。したがって、
このようなフィールドにインデックスを作成すると、テーブル全体のクエリ速度が向上します。

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

インデックスが多ければ多いほど良いです。各インデックスにはディスク領域が必要です。インデックスの数が増えるほど、必要なディスク領域も増えます。
テーブルを変更する場合、インデックスの再構築と更新は面倒です。インデックスの数が増えるほど、テーブルの更新にかかる時間が長くなります。

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

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

6.プレフィックスインデックスの使用を試みる

インデックス フィールドの値が非常に長い場合は、値のプレフィックスを使用してインデックスを付けることをお勧めします。たとえば、TEXT および BLOG タイプのフィールドの場合、全文検索は時間の無駄になります。フィールドの最初の数文字のみを検索すると、検索速度が向上します。

7.使用されなくなった、またはほとんど使用されないインデックスを削除します。

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

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

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

MySQL インデックスに関するヒント:

1. レコードをフィルタリングするためによく使用されるフィールド。

1. 主キーフィールドでは、システムが自動的に主キーインデックスを作成します。
2. 一意のキー フィールドの場合、システムは対応するインデックスを自動的に作成します。
3. 外部キー制約によって外部キーとして定義されたフィールド。

4. クエリでテーブルを結合するために使用されるフィールド。

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

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

3. インデックスの作成では、データの操作方法を考慮する必要があります。

1. コンテンツはほとんど変更されませんが、頻繁にクエリされるため、複数のインデックスを作成しても問題ありません。

2. 頻繁かつ定期的に変更されるテーブルの場合は、必要なインデックスを慎重に作成する必要があります。

4. 主キーとユニークキーの違い

1. 主キーとして使用されるドメインまたはドメイン グループは null にできません。しかし、Unique Key なら可能です。

2. テーブルには主キーは 1 つしか存在できませんが、一意キーは同時に複数存在できます。

最大の違いはロジック設計にあります。主キーは一般的にロジック設計のレコード識別子として使用され、設定でもあります。
主キーの本来の目的は、ドメイン/ドメイン グループの一意性を確保することです。

5. 複合指数と単一指数

複合インデックスとは、複数のフィールドの結合インデックスを指します。クエリを実行する場合、これらのフィールドはクエリの条件として組み合わされることがよくあります。

ユニークインデックスは主に主キーIDによってインデックス化され、ストレージ構造の順序は物理構造と一致します。

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

まずaでソートし、aが同じ場合はbでソートします。つまり、aまたはabを検索すると、

このインデックスを使用できます。ただし、b のみを検索する場合、インデックスはあまり役に立ちません。検索をスキップできる場合があります。

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

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

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

2. データ量が 300 万を超えるテーブルにはインデックスが必要です。

3. 他のテーブルに頻繁に接続されるテーブルの場合は、接続フィールドにインデックスを作成する必要があります。

4. Where 句に頻繁に出現するフィールド、特に大きなテーブル内のフィールドにはインデックスを付ける必要があります。

5. インデックスは選択性の高いフィールドに構築する必要があります。

6. インデックスは小さなフィールドに作成する必要があります。大きなテキスト フィールドや非常に長いフィールドにはインデックスを作成しないでください。

7. 複合インデックスの作成には慎重な分析が必要です。代わりに単一フィールド インデックスの使用を検討してください。

A. 複合インデックス内のプライマリ列フィールド（通常は選択性の高いフィールド）を正しく選択します。

B. 複合インデックスの複数のフィールドが AND モードの Where 句に同時に出現することがよくありますか?単一フィールドクエリはほとんどないか、まったくありませんか?はいの場合は、複合インデックスを作成できます。それ以外の場合は、単一フィールド インデックスを検討してください。

C. 複合インデックスに含まれるフィールドが Where 句に単独で頻繁に出現する場合は、複合インデックスを複数の単一フィールド インデックスに分解します。

D. 複合インデックスに 3 つ以上のフィールドが含まれている場合は、その必要性を慎重に検討し、複合フィールドを削減することを検討してください。

E. これらのフィールドに単一フィールド インデックスと複合インデックスがある場合、通常は複合インデックスを削除できます。

8. 頻繁にデータ操作を実行するテーブルには、インデックスをあまり多く作成しないでください。

9. 実行プランへの悪影響を避けるために、不要なインデックスを削除します。

上記は、インデックスを設定する際の一般的な判断基準です。要するに、指標の設定は慎重に行う必要があり、各指標の必要性を慎重に分析し、その設定には根拠がなければなりません。インデックスが多すぎる場合や、不十分または不正確なインデックスはパフォーマンスに何のメリットもありません。テーブルに作成された各インデックスはストレージのオーバーヘッドを増加させ、インデックスによって挿入、削除、および更新操作の処理オーバーヘッドも増加します。さらに、単一フィールド インデックスがある場合、複合インデックスが多すぎると通常は役に立ちません。逆に、頻繁に更新されるテーブルの場合は特に、データの追加や削除を行うときに、複合インデックスによってパフォーマンスが低下します。

上記の記事では、MySQL のインデックス設計の原則と一般的なインデックスの違いについて簡単に説明しました。これは、編集者が皆さんと共有する内容のすべてです。参考になれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。