目次
インデックスの使用法 (パート 2)
インデックスとテーブルの戻りクエリをカバーする
カバリング インデックスとは、クエリでインデックスが使用され、返される必要があるすべての列がインデックス内で見つかることを意味します。
まず、次の一連の SQL の実行プロセスを見て、インデックスとテーブルの戻りクエリについて理解を深めましょう。
テーブル構造とインデックス図:
id は主キーであり、クラスター化インデックスです。名前フィールドには共通インデックスが確立され、これが二次インデックス (補助インデックス) になります。
SQLを実行します。
select * from tb_user where id = 2;
ID クエリに従って、クラスター化インデックス クエリを直接使用します。インデックス スキャンでは ID が 2 と一致します。行データはクラスター化インデックスのリーフ ノードの下に配置されるため、必要なデータを取得して直接データを返すことができます。高いパフォーマンスで。
もう一度見てください、
SQLを実行します:
selet id,name from tb_user where name = 'Arm';
クエリは名前フィールドに基づいてセカンダリ インデックスがクエリされますが、クエリによって返されるフィールドは id と名前であるため、名前のセカンダリ インデックスではこれら 2 つの値を直接取得できます。したがって、テーブルをクエリバックする必要がなく、パフォーマンスが高くなります。
最後の様子、
SQLを実行します:
selet id,name,gender from tb_user where name = 'Arm';
name の 2 次インデックスには性別が含まれていないため、2 回のインデックス スキャン、つまりテーブル クエリが必要となり、パフォーマンスが比較的悪くなります。
MySQL の実行計画を見ると、一部の SQL ステートメントの実行計画の指標はすべて同じであり、違いは見られません。ただし、その背後にある追加機能に注目してください。
| 余分な | 意味 |
|---|---|
| where を使用する; インデックスの使用 | 検索にはインデックスが使用されますが、必要なデータはインデックス列で見つかるため、テーブルに戻ってデータをクエリする必要はありません。 |
| インデックス条件の使用 | 検索ではインデックスが使用されますが、データをクエリするにはテーブルを返す必要があります。 |
したがって、実行計画で Extra が「インデックス条件を使用する」になっている場合は、変更および最適化が必要になる可能性があります。
考える質問
テーブルには 4 つのフィールド (ID、ユーザー名、パスワード、ステータス) があります。データ量が多いため、次の
SQL ステートメントを最適化する必要があります。どのように進めるかが最適な解決策です:select id,username,password from tb_user where username = 'itcast';
答え：ユーザー名とパスワードの結合インデックスを作成します。
SQL は次のとおりです: createindex idx_user_name_pass on tb_user(username,password);
これにより、クエリ プロセス中に上記の SQL ステートメントとテーブルを返すクエリを回避できます。
プレフィックスインデックス
フィールド タイプが文字列 (varchar、text、longtext など) の場合、非常に長い文字列のインデックスを作成する必要がある場合があります。その場合、インデックスが非常に
大きくなり、クエリ中に大量のディスク IO が無駄になり、クエリの効率に影響します。
現時点では、文字列の一部にのみプレフィックスを付けてインデックスを作成できます。これにより、インデックス領域が大幅に節約され、インデックス作成の効率が向上します。
文法
create index idx_xxxx on table_name( column(n) );例
tb_user テーブルの email フィールドに長さ 5 のプレフィックス インデックスを作成します。
create index idx_email_5 on tb_user ( email(5) );
プレフィックスの長さ
これは、データ テーブル内のレコードの総数に対する一意のインデックス値 (カーディナリティ) の比率を指すインデックスの選択性に基づいて決定でき、インデックスの選択性が高いほど、クエリ効率が高くなります。一意のインデックスの選択性は 1 です。これは最良のインデックス選択性であり、最高のパフォーマンスが得られます。
select count(distinct email) / count(*) from tb_user ;
select count(distinct substring(email,1,5)) / count(*) from tb_user ;プレフィックスインデックスのクエリ処理
単一列インデックスと結合インデックス
単一列インデックス: インデックスには 1 つの列のみが含まれます。
ユニオンインデックス: インデックスには複数の列が含まれます。
実行プランでは、phone と name の 2 つのフィールドが単一列インデックスである場合、最終的に MySQL は 1 つのインデックスのみを選択します。つまり、1 つのフィールドのインデックスのみが使用できます。このとき、テーブルはクエリ。
ビジネス シナリオで複数のクエリ条件がある場合、クエリ フィールドにインデックスを作成することを検討するときは、単一列インデックスではなく結合インデックスを作成することをお勧めします。
インデックス設計の原則
- 大量のデータと頻繁なクエリを含むテーブルのインデックスを作成します。
- クエリ条件 (where)、並べ替え (order by)、およびグループ化 (group by) 操作としてよく使用されるフィールドのインデックスを作成します。
- 識別性の高い列をインデックスとして選択し、ユニークなインデックスを構築するようにしてください。識別性が高いほど、インデックスの使用効率が高くなります。
- 文字列型フィールドでフィールドの長さが長い場合、フィールドの特性に基づいてプレフィックス インデックスを確立できます。
- 結合インデックスを使用し、単一列インデックスを減らすようにしてください。クエリを実行する場合、結合インデックスは多くの場合、インデックスをカバーし、記憶領域を節約し、テーブル バックを回避し、クエリ効率を向上させることができます。
- インデックスの数を制御するには、インデックスの数が多いほど良いですが、インデックスの数が増えると、インデックス構造を維持するためのコストが増加し、追加、削除、変更の効率に影響します。
- インデックス付き列に NULL 値を格納できない場合は、テーブルの作成時に NOT NULL を使用して制約します。オプティマイザは、各列に NULL 値が含まれているかどうかを認識すると、クエリにどのインデックスを最も効率的に使用するかをより適切に決定できます。
インデックスの概要
1. インデックスの概要
インデックスは、効率的なデータ検索のためのデータ構造です。
2. インデックスの構造
B+ツリー
ハッシュ
3. 指数の分類
主キー インデックス、一意のインデックス、通常のインデックス、フルテキスト インデックス、クラスター化インデックス、セカンダリ インデックス。
4. インデックスの構文
xxx(xxx) に [一意の] インデックス xxx を作成します。
xxxx からのインデックスを表示します。
xxxx のインデックス xxx を削除します。
5.SQLパフォーマンス分析
実行頻度、遅いクエリのログ、プロファイル、説明。
6. インデックスの使用法
ユニオンインデックス、インデックス無効化、SQLプロンプト、カバリングインデックス、プレフィックスインデックス、単一カラム/ジョイントインデックス。
7. インデックス設計原則
テーブル、フィールド、インデックス。
終わり
学習内容: ダークホース プログラマー - MySQL データベース コース