I.はじめに
もう1つの属性で取得プロセスが完全に異なるのはなぜですか？
select id,name from user where name='shenjian'
select id,name,sex from user where name='shenjian'2.テーブルに戻るクエリとは何ですか？
これは、InnoDBのインデックスの実装から始まります。InnoDBには、次の2種類のインデックスがあります。
-
クラスター化されたインデックス（クラスター化されたインデックス）
-
普通指数（二次指数）
InnoDBクラスター化インデックスと通常のインデックスの違いは何ですか？
InnoDBクラスター化インデックスのリーフノードは行レコードを格納します。したがって、InnoDBには1つだけのクラスター化インデックスが必要です。
- テーブルがPKを定義している場合、PKはクラスター化されたインデックスです。
- テーブルでPKが定義されていない場合、最初のNULL以外の一意の列はクラスター化されたインデックスです。
- それ以外の場合、InnoDBはクラスター化されたインデックスとして非表示の行IDを作成します。
したがって、PKクエリは非常に高速で、行レコードを直接見つけます。
InnoDB通常インデックスのリーフノードは、プライマリキー値を格納します。
MyISAMのインデックスリーフノードは、行レコードヘッダーポインタを格納する代わりに、レコードポインタを格納することに注意してください。
たとえば、次のようなテーブルが必要な場合があります。
user(id PK, name KEY, sex, flag);idはクラスター化されたインデックスであり、nameは通常のインデックスです。
テーブルには4つのレコードがあります。
1、shenjian、m、A
3、張山、m、A
5、lisi、m、A
9、王武、f、B
2つのB +ツリーインデックスは、上の図に示すとおりです。
1. IDはPK、クラスター化されたインデックス、リーフノードは行レコードを格納します。
2.名前はKEY、共通のインデックスであり、リーフノードはPK値、つまりidを格納します。
通常のインデックスから直接行レコードを見つけることができないので、通常のインデックスのクエリプロセスは何ですか？
通常、インデックスツリーを2回スキャンする必要があります。
例えば：
select * from t where name='lisi';それはどのように実装されていますか？
以下のようなピンク色のパス、あなたは二回インデックスツリーをスキャンする必要があります。
- まず、通常のインデックスからプライマリキー値id = 5を見つけます。
- クラスター化されたインデックスから行レコードを見つけます。
これはいわゆるテーブルに戻るクエリであり、最初にプライマリキー値を検索し、次に行レコードを検索します。そのパフォーマンスは、インデックスツリーをスキャンする場合よりも低くなります。
3、インデックスカバレッジとは何ですか
MySQLの公式Webサイトでは、同様のステートメントがExplainクエリプランの最適化の章に表示されます。つまり、Explainの出力結果のExtraフィールドがUsing indexの場合、インデックスカバレッジをトリガーできます。
SQL-Serverの公式WebサイトであろうとMySQLの公式Webサイトであろうと、次のように表現されます。SQLに必要なすべての列データを取得できるのは1つのインデックスツリーだけであり、テーブルに戻る必要はありません。
第四に、インデックスカバレッジを達成する方法は？
一般的な方法は、ジョイントインデックスに照会するフィールドを作成することです。
最初のSQLステートメント：
select id,name from user where name='shenjian';名前インデックスにヒットでき、インデックスリーフノードにプライマリキーIDが格納され、IDと名前は、テーブルに戻らずに、インデックスカバレッジに準拠し、高効率で、名前のインデックスツリーから取得できます。
2番目のSQLステートメント：
select id,name,sex from user where name='shenjian';名前インデックスをヒットでき、インデックスリーフノードにプライマリキーIDが格納されますが、性別フィールドはテーブルクエリから取得する必要があります。インデックスカバレッジが満たされていない場合は、クラスター化されたインデックスをid値でスキャンして、性別フィールドを再度取得する必要があります。これにより、効率が低下します。
（名前）単一列インデックスを共同インデックス（名前、性別）にアップグレードする場合は異なります。
見られます：
select id,name from user where name='shenjian';
select id,name,sex from user where name='shenjian';どちらも、テーブルに戻らずにインデックスカバレッジに達する可能性があります。
5.インデックスカバレッジを使用してSQLを最適化できるシナリオはどれですか。
シナリオ1：完全なテーブルカウントクエリの最適化
元のテーブルは次のとおりです。
user(PK id, name, sex)；直接：
select count(name) from user;インデックスカバレッジは使用できません。
インデックスを追加：
alter table user add key(name);インデックスカバレッジを使用して、効率を向上させることができます。
シナリオ2：テーブルの最適化に戻る列クエリ
select id,name,sex from user where name='shenjian';この例では詳細については説明しません。テーブルに戻らないように、単一列のインデックス（名前）を結合インデックス（名前、性別）にアップグレードします。
シナリオ3：ページングクエリ
select id,name,sex from user order by name limit 500,100;テーブルに戻らないように、単一列のインデックス（名前）を結合インデックス（名前、性別）にアップグレードします。
InnoDBクラスター化インデックス通常インデックス、テーブルに戻る、インデックスカバレッジ。