干物編:あなたに1篇の文章を譲ります——《MySQL索引の原理を深く解析します》

概要
最近再びMySQLの内容を深く研究して、今日主にMySQLのインデックスの原理を分かち合って分析して、后でいくつかMySQLの方面の干物について出力して、各位の小さい仲间が好きであることを望みます.一、インデックスとは何か、なぜインデックスを作成するのか.

       ，                  ，                            。

                         ，       ，MySQL               ，        ，   ，             。             ，MySQL               ，         ，             。

(一)、インデックスのストレージファイルはどうなっていますか.
まずmysqlインデックスデータの格納場所を見てみましょう.
mysqlのデータ格納はmysqlのdataフォルダの下に格納され、スクリーンショットは以下の通りです.

          ，               ：

.frm     ，           。

（ ）、MyISAM       

1、mydデータファイル接尾辞
2、myiインデックスファイル接尾辞
(三)、InnoDBエンジンのファイルフォーマット
1、ibdインデックス情報とデータを一緒に記憶する
二、インデックスの構造は何ですか.なぜ別の構造を採用しないのですか?

                         ，           ，           ：

（ ）、             

             ，               。

      ：

（ ）、            

                    。          ，             ，                       。（         ，     ）

                           ，     ，        ，        ：

（ ）、hash     

   hash       ，         ：

 1、             

 2、    hash     

三、BTreeの理解方法

            ，              BTree。

（ ）、BTree          ：

（ ）、BTree            

 1、 (Degree)-         ，                  

 2、              

 3、         

 4、        key        

btree             ，      Btree   ，     io     。             3-5    。

四、ノードデータの読み込みプロセスで何が起こったのか.

         ，  io      ，            。                    ，                。

（ ）、      

                            ，               。                      ，          ，                     。                  ，               ，       io            。

btree        key-value       ，key      ，value    data  。      btree                     ，      io    ，   cpu       。

            ，             。

     ：

    ，          ，        （23），     7  io    。       ，           ，34-->22-->23    io              23。

（ ）、         ？

              ，        100W，  BTree       ，           ，    ？

         ，       。                                   。         ，io           ，              io  。

                                   ，                        ，             8k（          ），           10M,                    io  。（  DBA                                 。）

（ ）、   IO

                           ，        MySQL                          ，                  ，                                       。

    ，                        ，           ，                   ，            ；    ，             ，      。（             ）

ページ・サイズは、次の操作で表示できます.

  MySQL  ，        16KB，       8KB、32KB      ，   MySQL                    。

                        ，       。
 、    BTree   ？

各ノードのサイズが小さいほど、オペレーティングシステムが1ページのデータを読み取る内容が多くなり、メモリに格納できるデータ量が増加し、処理の効率が向上します.そこでB+Treeが誕生した.

（ ）、    B+Tree？

       B+Tree          ：

(二)、B+Treeのいくつかの重要な特徴:

1、        data，   key，       。

2、         。

3、順次アクセスポインタ、区間アクセスの性能を高める.

                         ，B+Tree                  ，                ，            。          key，     data  ，                   ，         io         ，                     。

    B+Tree       ，                   。

B+Tree                            。

                      BTree  ，                          ，                   ，             。

六、Myisam非クラスタインデックス

         mysql              。myisam      ，mysql               ，               ：.    myi--->.myd（                 ）

                           （                 ）

（ ）、    ：

         ，B+Tree        key       ，value      data     。

(二)、補助索引:

Myisam                  ，       

(三)、Innodbクラスタリングインデックス
前述したinnodbストレージでは、データとインデックスを同じファイルに格納しています.
したがってinnodbの非プライマリ・キー・インデックス(セカンダリ・インデックス)とプライマリ・キー・インデックスには一定の違いがあります.次に、図例を用いて詳細に比較して説明します.
innodb内のプライマリ・キー・インデックスと非プライマリ・キー・インデックス:
(四)、主キー索引
プライマリ・キー・インデックスの格納状況を下図に示すように、リーフ・ノードのkeyはインデックスの情報であり、valueはデータ・テーブルのインデックスに対応する行のデータ情報である.
(五)、非主キー索引
このインデックスが格納されると,ノードは依然としてkey-valueの構造であり,keyは対応するインデックスに対応するが,valueはプライマリキーインデックスの値に対応する.次の図に示します.

                       ，                              ASCII         。

七、なぜInnoDBテーブルにプライマリ・キーが必要なのか.

   innodb      ，              B+Tree         ，          。

手動でプライマリ・キーが設定されていない場合でも、innodbは自動的にデータの列を選択して設定するか、デフォルトでプライマリ・キーとして列を生成します.
(一)、uuidと自増idをプライマリキーとして使用する違い?
インデックスの原理を理解した後,自己増加idの代わりにuuidを用いることによる欠陥を下層から考えてみよう.
1、uuidの長さは一般的に自増idの長さより長いため、uuidはディスク領域をより占有する.
2、uuidは通常文字列の形式で存在するため、比較を行う際には文字列の形式に基づいて比較を行う(ack||コードを用いる)ことが多く、自増主キーはintegerの比較方式を用いる.効率の差が大きい.
3、uuidは、データの挿入を行う際に、度が満たされたノードに挿入される可能性があります.この場合、元の古いノードはノードの分割操作を行う必要があり、データの移動を行い、性能効率を低下させる必要があります.
(二)、連合インデックスの最下位ストレージ構造はどのようなものですか.
実際のプロジェクト開発では、コンビネーションインデックスは私たちがよく使う最適化テクニックの一つです.本稿では、最適化をしばらく言わずに、まず最下位からコンビネーションインデックスの格納方法を理解し、後で最適化の説明を展開します.たとえば、連合インデックスにid、職階名、生年月日の3つのフィールドが使用されると、格納時に3つのフィールドがノード内のkey位置に一緒に格納されます.次の図に示します.
インデックスノード内のkeyを比較する場合、id、職階名、生年月日の順(左から右)で比較します.比較するときは1対1で、指定したフィールドに一致しないとマッチングは継続されません.これも複合インデックス内の面の最も左の接頭辞マッチングの原則です.
MySQLインデックスについての基本的な紹介は大体これだけですが、インデックスの最適化については後でシリーズのドライアウトプットを行いますので、皆さんに楽しんでもらいたいです.