記事のディレクトリ
1. B +ツリーインデックスの分類
1.1クラスタ化インデックス
B +ツリーを構成する各テーブルの主キーによれば、テーブル全体のデータ列を格納するリーフノードは、リーフノード・ページ・データが各データページ間の双方向リンクリストによって連結されるインデックスをクラスタ化します。データページは、各行のすべてのレコードに格納され、データ・ページは、非オフセットおよびデータページへのキーに格納されています。表は1クラスタ化インデックスを持つことができます
- データは、リーフノードに直接見つけることができます
- 集計インデックスは、論理的に連続しているため、検索速度の主ソートキーのルックアップと範囲については、非常に高速です。例えば、原因B +ツリーインデックスへのクエリ10のデータは、二重に、あなたはすぐにデータ・ページを見つけることができ、その後、10データの最後を削除し、リストをリンクされています
1.2セカンダリインデックス
また、各テーブルのインデックス列をB +ツリーを作成するために作成されているによると、非クラスタ化インデックスとして知られている、リーフ・ノードは、データ行の全てが含まれていません。リーフノードは、データの通常クラスタ化インデックスキー襄陽行、そのインデックスに対応するデータの行を見つけるために、InnoDBストレージエンジンに通知するために使用可能なキーやブックマークを含みます。各テーブルには、複数のセカンダリインデックスを持つことができます
クエリがセカンダリインデックス、検索プロセスを介してデータを見つけることである場合：セカンダリインデックスの最初のトラバーサルおよび主キー主キーインデックスを取得するためのポインタを見つけるために、リーフノードを見つけ、その後、レコードの完全なラインを見つけるために、主キーのインデックスで対応するページを見つけます。注：私はかつてIOは、3つのセカンダリインデックスの木の高さなど、2のインデックスツリーの高さをクラスタ化され、クエリデータは、3 + 2 IOは論理データ・ページで終わるセカンダリインデックスを通じて行われるクエリを実行しませんでした
2.
2.1関節指数
関節インデックスはB +ツリーであるが、そのような関節指標として複数のキーの数、（B）Bがに関して順序付けされるが、そのような（3のような方法の二次元データを、理解することができ5）、キーは、テーブルが次の文を使用して作成された右（3,5）以上である）、（3,5よりも小さくします
create tablebuy_log (
userid int Unsigned not null,
num int,
buy_date Date
)
//创建两个索引：userid，userid_2
Alter table buy_log add key(userid); //userid
Alter table buy_log add (userid,num,buy_date) //userid_2
select * from buy_log where userid=2;後補助リーフノードのインデックスは、単一のキーが含まれているため、分析は、ユーザーIDのインデックスを使用しますEXPLAIN、ページは理論的には複数のレコードを格納することができますselect * from buy_log where userid =1 and num=2 order by buy_date Desc limit 3後の分析は、ソートされた余分なペアbuy_dateを行うにソートしているので、buy_date共同インデックスの、（ユーザーID、NUM、buy_date）共同インデックスuserid_2を使用して、ではないであろうEXPLAIN。ユーザーIDのインデックスbuy_dateが順序付けられていないので、あなたがインデックスindexのユーザーIDを強制する場合は、分析の後、filesortレコードをUseingソート操作を行います、それは、ソートbuy_dateですselect * from buy_log where userid =1 order by buy_date Desc limit 3（ユーザーID、buy_date）が順不同であるため後、分析は、ユーザーIDのインデックスを使用するEXPLAIN、インデックスが組み合わせて使用されず、ソート処理
2.2被覆率
また、インデックス・カバレッジとして知られているインデックスをクラスタ化されたレコードを照会する必要がなく、インデックスの補助記録の確認、から入手することができます。
持っている2つの大きな利点がある被覆インデックスを使用します。
- セカンダリインデックスはそんなに小さいクラスタ化インデックスのサイズよりも、全体の行のすべての情報が含まれていない、大量が少ないIO操作することができ
- 統計を行うと、統計は、セカンダリインデックスは、統計によって達成することができ、クラスタ化インデックスを通ってくるが、また、IOを減らしません。
上記で作成したテーブルとインデックスを使用して、その後、イラストカバーインデックスの方法によって：
select count(*) from buy_log後の分析をEXPLAIN、ユーザーIDセカンダリインデックスを使用しますが、その後、インデックスはインデックスの使用のためのエキストラをカバーすることです- SELECT COUNT（*）buy_logから buy_date> = '2019年1月1日'とbuy_date < '2019年6月7日'は、組み合わせ指数（ユーザーID、NUM、buy_date）で使用することができるスルー分析をEXPLAIN 通常の状況下ではありません共同インデックスは、インデックスによってカバーされた情報を使用することができ、あなたが望む結果を得ることができ、行われるが、これは統計的なSQL操作でた、オプティマイザは、関節のインデックスを選択します
全表スキャン：2.3オプティマイザはインデックスNAを選択します
つまり、データを検索するためにインデックスを使用することではなく、クラスタ化インデックスをスキャンすることによって、つまり、完全なテーブルは、データを取得するために直接スキャン。このような状況はで発生したリンクに参加し、検索の範囲などを次の表には、それを介して順序を示しています。
select * from orderdetails where orderid > 10000 and orderid<102000;
即ち未満102,000の情報注文番号10000、テーブルの順序は、単一指数（受注）が関節指数（受注コード、商品コード）が存在したよりも大きい、上記の文章は、データを検索するために索引を介して明らかとなるであろう（受注）を探しますしかし、後の分析をEXPLAIN、オプティマイザは、ユーザーID検索インデックスデータを選択しますが、テーブルスキャンである主クラスタ化インデックスの選択、その理由ではないのですか？？？ユーザーが選択したデータは、データの行全体をあるので、指定されたデータに後の受注指数クエリは、また、データの行全体にアクセスするためのブックマークを見つける必要があるため、セカンダリインデックスは、私たちが照会したい情報を網羅することはできません。データ受注指数が順番に格納されますがされているが、再びブックマークルックアップデータが乱れているため、個別のディスク上に読み込むになります。めったにアクセスされないデータの量が（20％）、オプティマイザは、データを見つけるためにクラスタ化インデックスを選択します場合。ので、シーケンシャルがはるかに高速分散がより読み
インデックスケースでカバーすることができない、オプティマイザは、セカンダリインデックスのためのケースを選択します：セカンダリインデックスを介してデータを検索し、少量であるが、ディスクは、ソリッドステートディスクの場合はランダム読み取り操作を迅速かつセカンダリインデックスは、より良いパフォーマンスにつながることを確認し、使用したインデックスの使用を強制するキーワードFORCEインデックスを
select * from orderdetails FORCE INDEX(userid) where orderid > 10000 and orderid<102000;
使用中の前に、このような問題が発生した場合は、クエリ時間を使用し、時間フィールドは、インデックス化、実行時の発見は時々インデックスを打つことができ、時には命はないが、今この時点ではヒットしない理由を理解し、データの量ですあまりにも、行くことを余儀なくされたインデックスを使用することで、データベースは約3秒インデックスのみ約1秒の必須使用後にインデックスのクエリを使用していませんでした前30万データを持っています
MySQLのインデックスの問題の詳細については、https://blog.csdn.net/wrs120/article/details/80711800を