MySQLの高度な（2）インデックスの導入と使用

4.インデックスの概要

4.1インデックスとは何ですか？

インデックスはMySQLがデータを効率的に取得するのに役立つデータ構造であり、インデックスはデータ構造です。
インデックス作成の目的は、クエリの効率を向上させることです。これは、辞書と比較できます。
インデックスは、データベースシステムが検索アルゴリズムの特性を満たすために維持するデータ構造です。これらのデータ構造は、特定の方法でデータを参照（ポイント）します。
一般的に、インデックスも非常に大きく、すべてをメモリに保存することは不可能であるため、インデックスはインデックスファイルの形式でディスクに保存されることがよくあります。

概要：ソートされた高速検索データ構造はインデックスであるため、インデックスはWHEREおよびORDERBYキーワードの背後にある条件付きフィルタリングに影響します。

私たちが通常話しているインデックスは、特に指定されていない限り、** Bツリー（複数検索ツリー）**の組織構造のインデックスを指します。その中で、クラスター化インデックス、適合インデックス、プレフィックスインデックス、および一意のインデックスはすべて、デフォルトでB +ツリーインデックスを使用します

4.2 2フォークBTREEインデックスデータ構造の場合：

ここに写真の説明を挿入

Col2の検索を高速化するために、右に示すようにバイナリ検索ツリーを維持できます。各ノードには、インデックスキー値と、対応するデータレコードの物理アドレスへのポインタが含まれているため、特定の複雑さの範囲内で2つの検索を使用できます。条件を満たすレコードをすばやく取得できるように、対応するデータを取得します。

注：データを追加または削除するときは、インデックスが無効にならないようにインデックスを変更する必要があります。したがって、頻繁に追加または削除されるデータにはインデックス付けはお勧めしません。論理的削除（フラグビット削除）を使用して、削除の問題を解決できます。

4.3インデックス作成の長所と短所：

利点：

类似大学图书馆建书目索引，提高数据检索的效率，降低数据库的IO成本
通过索引列时数据进行排序，降低数据排序的成本，降低了CPU的消耗

劣势：

实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，索引索引列也是要占空间的
虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息，数据位置修改的同时需要修改索引
索引只是提高效率的一个因素，如果MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，优化查询

4.4 索引的分类：

单值索引：即一个索引只包含单个列，一个表可以有多个单值索引
唯一索引：索引列的值必须唯一，但允许有空值
复合索引：一个索引包含多个列

基本语法：

创建

CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length));

ALTER mytable ADD [UNIQUE] INDEX [indexName] ON (columnname(length));

删除

DROP INDEX [indexName] ON mytable;

查看

SHOW INDEX FROM table_name

4.5 MySQL索引结构：

MySQL支持4种索引结构：BTREE索引、Hash索引、full-text索引、R-Tree索引，java开发主要使用BTREE索引。

BTREE索引：

ここに写真の説明を挿入

【初始化介绍】

上の図のB +ツリーでは、水色のブロックはディスクブロックと呼ばれています。各ディスクブロックには、いくつかのデータ項目（濃い青色で表示）とポインター（黄色で表示）が含まれていることがわかります。たとえば、ディスクブロック1には、ポインタP1、P2、およびP3を含むデータ項目17および35が含まれます。P1は17より小さいディスクブロックを示し、P2は17〜35のディスクブロックを示し、P3は35より大きいディスクブロックを示します。

実際のデータはリーフノード、つまり3,5,9,10 ...に存在します。非リーフノードは実際のデータを格納せず、valueは、データテーブルに実際には存在しない17、35などの検索方向をガイドするデータ項目を格納します。

【検索プロセス】

データ項目29を検索する場合は、最初にディスクブロック1をディスクからメモリにロードします。この時点でIOが発生します。バイナリ検索を使用して、29がディスク内で17〜35であることを確認し、ディスクブロック1のP2ポインタをロックします。メモリ時間は（ディスクIOと比較して）非常に短く、無視できます。ディスクブロック3は、ディスクブロック1のP2ポインタのディスクアドレスを介してディスクからメモリにロードされ、2番目のIOが発生し、ディスクブロック3のP2ポインタがバイナリ検索によってロックされ、ディスクブロック8がポインタを介してメモリにロードされ、3回目が発生します。 IO、クエリの終わり。

実際の状況では、3層のB +ツリーは数百万のデータを表すことができます。数百万のデータ検索に必要なIOが3つだけの場合、パフォーマンスは大幅に向上します。インデックスがない場合、各データ項目は1回発生します。 IOの場合、合計で数百万のIOが必要になりますが、これは明らかに非常にコストがかかります。

4.6インデックス確立の分析：

4.6.1インデックスを作成するために必要な状況：

主キーは自動的に一意のインデックスを作成します
クエリ条件でインデックスを作成する場所として頻繁に使用されるフィールド
クエリ内の他のテーブルに関連付けられているフィールドをクエリし、外部キー関係のインデックスを作成します
クエリ内の並べ替えられたフィールド。並べ替えられたフィールドにインデックスを介してアクセスすると、並べ替え速度が大幅に向上します。
グループ化はソートする必要があるため、クエリの統計またはグループ化フィールド
同時実行性が高いと、複合インデックスが作成される傾向があります

インデックスが検索と並べ替えによる順序付けのためのものである限り

4.6.2インデックスを作成する必要がない状況：

テーブルレコードが少なすぎます
頻繁に追加、削除されるテーブル
繰り返されて均等に分散されたデータを含むテーブルフィールド。したがって、最も頻繁にクエリされ、最も頻繁にソートされるデータ列のインデックスのみを作成する必要があります。データ列に重複するコンテンツが多数含まれている場合、インデックスを作成しても実用的な効果はあまりありません。

インデックスの選択性とは、テーブル内のレコード数に対するインデックス列の異なる値の数の比率を指します。テーブルに2000レコードがあり、テーブルインデックス列に1980の異なる値がある場合、このインデックスの選択性は1980/2000 = 0.99です。インデックスの選択性が1に近いほど、インデックスの効率は高くなります。

MySQLの高度な（3）インデックスの導入と使用