MySQL の単純なインデックス プラン分析

Mysql の簡単なインデックス

1. インデックスがない場合の検索方法

概念は無視してください。まずインデックスを付けて、特定のレコードを今すぐ確認したい場合、どのように検索すればよいでしょうか?

ページ内の検索

テーブル内のレコードが非常に少なく、1 ページで十分な場合は、次の 2 つの状況が考えられます。

• Use主キーを検索条件とする: これは前の記事で説明した方法です。二分法を使用してページ ディレクトリ内のスロットをすばやく見つけ、スロットのグループに対応するレコードを走査し、最終的に指定されたレコードを見つけます。 。

• 他の非主キー列を検索条件として使用する: データ ページには非主キー列用のページ ディレクトリがないため、二分法ではスロットをすぐに見つけることができません。 Infimum レコードから開始できるのは 1 回だけです。単一リンクされたリスト内の各レコードをたどるのは非効率です。

多くのページで検索

テーブルに多くのレコードがある場合、それらを保存するために多くのデータ ページが使用されます。この場合、次の 2 つの手順が必要です。

• レコードが置かれているページを見つけます。

• ページ内を検索する上記のプロセスを繰り返します。

一般的に、インデックスがない場合、レコードが配置されているページをすぐに見つけることができません。最初のページから二重リンクのリストをたどることしかできません (ページには、前のページと次のページ) 検索を続け、各ページで上記のプロセスを繰り返して、指定されたレコードをクエリします。これにはすべてのレコードを走査する必要があり、非常に時間がかかります。

2. 簡単なインデックス

ページ数が多すぎて位置情報の記録が遅いのですが、どうすれば解決できますか? 「ページディレクトリ」を参照するとよいでしょう。

ページ ディレクトリは、主キーに基づいてページ内のレコードの位置をすばやく特定できるように設定されています。したがって、レコードが配置されているページをすばやく見つけるために「他のディレクトリ」を作成する方法を検討できます。

しかし、この「他のディレクトリ」を完成させるには、行う必要があることが 2 つあります。

1. 次のページのユーザー レコードの主キー値は、前のページの値より大きくなければなりません。

各データ ページに最大 3 つのレコードを保持できると仮定します (実際には多数のレコードが保持されます)。配置できます)、次にテーブルに 3 つのレコードを挿入します。各レコードには 3 つの列 c1、c2、および c3 があります。便宜上、ストレージ行の形式も簡素化され、キー属性のみが残ります。仮想レコード Infimum と Supremum はそれぞれユーザー レコードの先頭と末尾に位置し、中間に 3 つのユーザー レコードがあります。

現時点では、引き続き 1 レコードを挿入します。仮定のケースでは、少なくとも 1 つの新しいページを割り当てる必要があるため、2 つのページが再割り当てされ、再配置されます。

赤色のフォントで示されている 2 つのレコードには、主キー 4 を持つ新しく挿入されたレコードが含まれており、新しいページに配置する必要があることに注意してください。ただし、次のページのユーザーレコードの主キー値が前のページのユーザーレコードの主キー値より大きくなければならないという要件を満たすために、レコードの移動などの操作が実行されます。 「ページ分割」と呼ばれます。

また、新しいページが 11 ページではなく 28 ページなのはなぜですか?ページはディスク上で隣り合っていない可能性があるため、前のページと次のページの番号を維持することによってリンク リスト関係を確立するだけです。

2. すべてのページのディレクトリ エントリを作成します

次に、テーブルへのデータの追加を続けます。複数のページ間の最終的な関係は次のようになります:

隣接しない複数のページからレコードをすばやく見つけるには、これらのページがディスク上で連続していない可能性があるため、それらのページ用にディレクトリをコンパイルする必要があります。

各ページはディレクトリ エントリに対応し、各ディレクトリ エントリには次のものが含まれます。

• key で表される、ページのユーザー レコード内の最小の主キー値

• page_noで表されるページ番号

したがって、それらをカタログ化した後の関係は次のようになります:

それでは、主キー値 20 を持つレコードを検索したいと思います。これを 2 つのステップで行います。

二分法を使用して、主キーを持つレコードを素早く特定します。ディレクトリ エントリの項目 3 の値 20、そのページ番号は 9 です。それが 9 ページにあることがわかっているので、前のアプローチを繰り返して、最終的なターゲット レコードを見つけます。

この時点で、簡単な計画が完成しました。完成した簡易ディレクトリには、index というエイリアスが付けられます。

3. 簡易索引で浮き彫りになる問題点

上記の簡易索引は、原書の著者が読者が段階的に理解できるように設定した内容であり、索引付けではありません。 innodbの計画。

次に、上記で提案されたインデックスを見て、どのような問題があるかを確認します。

質問 1:

InnoDB は、ストレージ スペースを管理するための基本単位としてページを使用します。つまり、最大 16 KB の連続ストレージしか保存できません。

テーブル内のレコードが増えると、すべてのディレクトリ エントリを保持するために非常に大きな連続ストレージ スペースが必要になりますが、大量のデータを含むテーブルではこれは現実的ではありません。

質問 2:

レコードの追加、削除、変更が必要になることがよくありますが、これは全体に影響します。

たとえば、上の図の 28 ページのすべてのレコードを削除した場合、28 ページは存在する必要がなく、ディレクトリ エントリ 2 も存在する必要はありません。このとき、ディレクトリ項目 2 以降のディレクトリ項目を前方に移動する必要があります。

ディレクトリ エントリ 2 を移動しない場合でも、ディレクトリ エントリ リストに冗長としてディレクトリ エントリ 2 を配置すると、依然として大量のストレージ スペースが無駄になります。

以上がMySQL の単純なインデックス プラン分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。