Mysqlインデックスまとめ
インデックス分類プライマリ・キー・インデックス・カラムの値は一意でなければなりません.NULL値は許可されません. 通常のインデックスMySQLの基本インデックスタイプで、定義されたインデックスの列に重複値と空の値を挿入できます. 一意インデックス列の値は一意でなければなりませんが、NULL値を許可します. 全文インデックスは、テキストタイプCHAR,VARCHR,TEXTタイプフィールドにのみ全文インデックスを作成できます.フィールドの長さが大きい場合、通常のインデックスを作成すると、likeファジイクエリで効率が低下し、全文インデックスを作成できます.MyISAMとInnoDBでは全文インデックスを使用できます. 空間インデックスMySQLは5.7以降のバージョンで空間インデックスをサポートし、OpenGISジオメトリデータモデルをサポートしています.MySQLは空間インデックスの面でOpenGISジオメトリデータモデルのルールに従います. プレフィックスインデックスは、CHAR、VARCHR、TEXTクラス列などのテキストタイプでインデックスを作成する場合に、インデックス列の長さを指定できますが、数値タイプでは指定できません.
インデックス構造としてB+ツリーを使用する理由
B+ツリーの非リーフノードは、リーフノードに冗長であり、リーフノード間がポインタで接続されているため、範囲検索の効率を向上させることができます.
Hashをインデックス構造として使用するのはいかがですか?
「卵」をハッシュアルゴリズムで直接計算し、データから直接データを取り出し、対応する行のデータのアドレスを取得し、その行のデータをクエリーすることができます.次に、次のsql文を実行します.
select*from sangoo where name>'卵'
ハッシュ・テーブルの特徴は、迅速な正確なクエリーですが、範囲クエリーはサポートされていません.
したがってハッシュテーブルはクエリに適したシーンであり,KV(Key,Value)のみの場合,例えばRedis,MemcachedなどのNoSQLのミドルウェアである.
インデックス構造としてツリーを使用するのはいかがですか?
インデックスもメモリに格納されているだけでなく、ディスクを落として永続化する必要があります.図にはこのようなデータが表示されます.データが多ければ、ツリーの高さが高くなり、クエリーのコストはツリーの高さとともに増加します.
コストを節約するために多くの会社のディスクを採用しているのか、機械的なハードディスクを採用しているのか、このような1回の千万級のクエリーの差は10秒もかかりません.これは誰が耐えられますか.
集計インデックスと非集計インデックスクラスタリングインデックス:データの格納順序をインデックス順序と同じにし、インデックスを見つけるとデータ が見つかる.非クラスタインデックス:インデックス分割構造にデータを格納し、インデックス構造のリーフノードがデータの対応する行 を指す.
各InnoDBテーブルには、クラスタインデックス(クラスタインデックス、クラスタインデックス、クラスタセットインデックスとも呼ばれる)と呼ばれる特殊なインデックスがあります.テーブルにプライマリ・キーが定義されている場合、そのプライマリ・キー・インデックスはクラスタ・インデックスです. プライマリ・キーが定義されていない場合、MySQLは最初のユニーク・インデックス(unique)を取得し、非空のカラム(NOT NULL)のみをプライマリ・キーとして含み、InnoDBはクラスタ・インデックスとして使用します.このような列がなければ、InnoDBは6バイトのID値を生成し、クラスタインデックスとして非表示にします.
テーブル内のクラスタリングインデックス(clustered index)は1級インデックスであり、それ以外のテーブル上の他の非クラスタリングインデックスは2級インデックスであり、補助インデックス(secondary indexes)とも呼ばれる.
プライマリ・インデックスとセカンダリ・インデックス(Secondary key)は構造的に何の違いもありませんが、プライマリ・インデックスはkeyが一意であることを要求し、セカンダリ・インデックスのkeyは繰り返すことができます.
時計は何ですか.
回表は、IDのプライマリ・キーを持つインデックスと、通常のnameフィールドのインデックスです.通常のフィールドで検索します.
select * from table where name = ‘hello’
実行されるプロセスは、nameインデックスの「hello」をクエリーし、idが2であることを検索し、最後にプライマリ・キー・インデックスを削除し、idが2に対応する値を検索します.
プライマリ・キー・インデックス・ツリーに戻って検索するプロセスは、テーブルに戻ります.
結局、通常のインデックスではローレコードを直接位置決めできないためです.
≪表に戻る｜Back Table｜oem_src≫:二次索引が(SQLでselectに必要なすべての)列のデータに直接問い合わせることができない場合、二次索引によってクラスタリング索引(すなわち、一級索引)に問い合わせると、(二次索引では提供できない)データに基づいて(二次索引では提供できない)データを問い合わせる.
インデックスを上書きしてテーブルに戻るのを避けるにはどうすればいいですか?
インデックスを上書きしてインデックスを上書きする方法は、クエリーされたフィールドを連合インデックスに作成することです.
テーブルを読むことなくインデックスを読み取り、データ・アクセスを大幅に削減します.
非クラスタインデックスは必ずテーブルクエリに戻りますか?
必ずしも、クエリ文に必要なフィールドがすべてインデックスにヒットしているかどうかについては、インデックスがすべてヒットしている場合は、テーブルクエリに戻る必要はありません.
簡単な例を挙げると、従業員テーブルの年齢にインデックスを確立したと仮定すると、
最も左のマッチングの原則は何ですか?
MySQLは範囲クエリに遭遇するまで右に一致します(>,
インデックス(a,b,c,d)、クエリー条件a=1 and b=2 and c>3 and d=4があると、各ノードでa,b,cの順にヒットし、dにヒットできない.(cはもう範囲クエリーですから、dは順番に並べられないに違いありません)
インデックス構造としてB+ツリーを使用する理由
B+ツリーの非リーフノードは、リーフノードに冗長であり、リーフノード間がポインタで接続されているため、範囲検索の効率を向上させることができます.
Hashをインデックス構造として使用するのはいかがですか?
「卵」をハッシュアルゴリズムで直接計算し、データから直接データを取り出し、対応する行のデータのアドレスを取得し、その行のデータをクエリーすることができます.次に、次のsql文を実行します.
select*from sangoo where name>'卵'
ハッシュ・テーブルの特徴は、迅速な正確なクエリーですが、範囲クエリーはサポートされていません.
したがってハッシュテーブルはクエリに適したシーンであり,KV(Key,Value)のみの場合,例えばRedis,MemcachedなどのNoSQLのミドルウェアである.
インデックス構造としてツリーを使用するのはいかがですか?
インデックスもメモリに格納されているだけでなく、ディスクを落として永続化する必要があります.図にはこのようなデータが表示されます.データが多ければ、ツリーの高さが高くなり、クエリーのコストはツリーの高さとともに増加します.
コストを節約するために多くの会社のディスクを採用しているのか、機械的なハードディスクを採用しているのか、このような1回の千万級のクエリーの差は10秒もかかりません.これは誰が耐えられますか.
集計インデックスと非集計インデックス
各InnoDBテーブルには、クラスタインデックス(クラスタインデックス、クラスタインデックス、クラスタセットインデックスとも呼ばれる)と呼ばれる特殊なインデックスがあります.
テーブル内のクラスタリングインデックス(clustered index)は1級インデックスであり、それ以外のテーブル上の他の非クラスタリングインデックスは2級インデックスであり、補助インデックス(secondary indexes)とも呼ばれる.
プライマリ・インデックスとセカンダリ・インデックス(Secondary key)は構造的に何の違いもありませんが、プライマリ・インデックスはkeyが一意であることを要求し、セカンダリ・インデックスのkeyは繰り返すことができます.
時計は何ですか.
回表は、IDのプライマリ・キーを持つインデックスと、通常のnameフィールドのインデックスです.通常のフィールドで検索します.
select * from table where name = ‘hello’
実行されるプロセスは、nameインデックスの「hello」をクエリーし、idが2であることを検索し、最後にプライマリ・キー・インデックスを削除し、idが2に対応する値を検索します.
プライマリ・キー・インデックス・ツリーに戻って検索するプロセスは、テーブルに戻ります.
結局、通常のインデックスではローレコードを直接位置決めできないためです.
≪表に戻る｜Back Table｜oem_src≫:二次索引が(SQLでselectに必要なすべての)列のデータに直接問い合わせることができない場合、二次索引によってクラスタリング索引(すなわち、一級索引)に問い合わせると、(二次索引では提供できない)データに基づいて(二次索引では提供できない)データを問い合わせる.
インデックスを上書きしてテーブルに戻るのを避けるにはどうすればいいですか?
インデックスを上書きしてインデックスを上書きする方法は、クエリーされたフィールドを連合インデックスに作成することです.
テーブルを読むことなくインデックスを読み取り、データ・アクセスを大幅に削減します.
非クラスタインデックスは必ずテーブルクエリに戻りますか?
必ずしも、クエリ文に必要なフィールドがすべてインデックスにヒットしているかどうかについては、インデックスがすべてヒットしている場合は、テーブルクエリに戻る必要はありません.
簡単な例を挙げると、従業員テーブルの年齢にインデックスを確立したと仮定すると、
select age from employee where age < 20のクエリーを行うと、インデックスのリーフノードにage情報が含まれており、再度テーブルクエリーを行わない.最も左のマッチングの原則は何ですか?
MySQLは範囲クエリに遭遇するまで右に一致します(>,
インデックス(a,b,c,d)、クエリー条件a=1 and b=2 and c>3 and d=4があると、各ノードでa,b,cの順にヒットし、dにヒットできない.(cはもう範囲クエリーですから、dは順番に並べられないに違いありません)