高度なMySQLの
1.インデックス
1.1概要インデックス
インデックスのMySQLの正式な定義は次のとおりです。インデックス(指数)は、MySQLが効率的にデータ(注文)のデータ構造を得るのを助けるためです。データに加えて、データベース・システムはまた、データ構造は、特定の検索アルゴリズム、データ構造及びデータ(ポイント)いくつかの基準を満たし維持し、インデックスデータを以下に示します:
左の表は、2〜7のレコードの合計、左端がデータレコード(論理的にディスク上に記録注意に隣接しても、必ずしも物理的に隣接していない)の物理アドレスである、データテーブルである。Col2にして下さい加速するために、あなたができます右図の維持バイナリ検索ツリーを、各ノードはすぐに取得した応答データを検索し、バイナリツリーを使用することができるように、インデックス値、それぞれ、と記録されたデータに対応する物理アドレスへのポインタが含まれています。
一般的には、インデックス自体は、インデックスは、インデックスファイルがディスク上に格納されているの形であることが多いので、すべて、メモリに格納されていない、また、偉大な一般的である。インデックスは、データベースのパフォーマンスを向上させるために最もよく使用されるツールです。
1.2長所と短所インデックス
利点:
1)ディレクトリ・インデックス・書籍と同様に、データの検索効率を向上させる、データベースIOのコストを削減
- インデックス列によって、データのソートデータのソートのコストを削減し、CPUの消費量を削減します
短所:
1)それは、実際にインデックス列は、空間であるので、主キーインデックスフィールド、及びポイント記録エンティティクラスに格納されたインデックステーブルです。
2)インデックスが大幅クエリ効率を向上させるだけでなく、そのようなテーブルのINSERT、UPDATE、DELETEのように、テーブルの更新速度を低下させるが、表が更新されたときしたがって、MySQLはデータを保存するだけでなく、各更新を添加したインデックスファイルについて保存するだけでなくフィールドの列のインデックス、および新しいとキー変更後のインデックス情報をもたらすために調整されます。
1.3インデックスの構造
インデックスはないサーバレイヤに実装MySQLストレージエンジンに実装されているので、各ストレージエンジンのインデックスは、すべてのストレージエンジンは、インデックスのすべてのタイプをサポートしない、必ずしも同一ではありません。MySQLは現在、次の4つの指標を提供しています:
-
BTREEインデックス:インデックスの最も一般的なタイプは、インデックスが最もBのインデックス番号をサポートしています。
-
HASHインデックス:専用メモリエンジンのサポート、簡単なシナリオの使用
-
R-treeインデックス(空間索引):インデックスが通常より少なく、主に地理空間データ・タイプについて、空間インデックス型のMyISAM特定のエンジンであります
-
全文(フルテキストインデックス):フルテキストインデックスは、主にフルテキストインデックスのために、特別なインデックスタイプMyISAMテーブルでは、Mysql5.6バージョンからInnoDBはフルテキストインデックスをサポートするために始めました。
インデックスの様々なタイプのためのMyISAM、InnoDBは、メモリー3つのストレージエンジンのサポート
指数 | InnoDBエンジン | MyISAMエンジン | メモリー・エンジン |
---|---|---|---|
BTREEインデックス | サポート | サポート | サポート |
HASHインデックス | サポートしていません。 | サポートしていません。 | サポート |
R-treeインデックス | サポートしていません。 | サポート | サポートしていません。 |
全文 | バージョン5.6は、以下をサポートしています | サポート | サポートしていません。 |
我々は通常、インデックス、指定されていない場合は、Bの+ツリー(複数の探索木、必ずしもバイナリ)組織クラスタ化インデックス、複合インデックス、接頭辞インデックスのインデックス構造、唯一のインデックスが既定値であると言っていますB +ツリーインデックスツリーは、インデックスと呼ばれる、使用されます。
1.3.1BTREE構造
多重化として知られるB木の平衡ツリー次のように、MフォークB木一般的な特徴は次のとおりです。
- ツリーまで各ノードは子メートルが含まれています
- ルートノードとリーフノードに加えて、各ノードは、少なくとも[CEIL(M / 2)]の子を有します。
- ルートがリーフノードでない場合には、少なくとも2人の子供があります
- すべてのリーフノードは、再び同じレベルを持っています。
- 各[CEIL(M / 2)] 1つのポインタNおよびN +による非リーフノードのキー、<= N <= M-1
B木は、例えば、キーの数を5フォーク:式導出[CEIL(M / 2)-1 <= N <= M-1 SO 2 <= N <= 4の場合にはN> 4、中間ノード分割します。親ノードに、両側のノードが分割しました。
たとえばCNGAHEKQMFWLTZDPRXYSのためのデータを挿入し、
次のように進化は以下のとおりです。
1)最初の4文字の空の正方形ポインタ以下CNGA()内に挿入されます
- インサートH、N> 4は、中間要素は、新しいノードに文字Gを分割しました
3)挿入E、K、Qは、分割を必要としません。
4)Mが挿入され、中間素子Mの文字は、親ノードGに分割しました
5)を挿入し、F、W、L、Tは、分割する必要はありません
6)を挿入Z、T中間要素は、親ノードに分割しました
7)Dが挿入され、中間要素は、Dは、次いで、P、R、X、Yの必要はないスプリットに挿入されたノードに分割しました
8)最後に挿入S、NPQRノードN> 5では、Qは、中間ノードを分割するが、分割DGMTの親ノードN> 5、中間ノードMまでの分割
これ、同じデータ、バイナリツリーよりも小さい階層構造BTREE、のためので、高速を検索するので、完全な、BTREEの木とバイナリ比較、より効率的なデータクエリを構築するためのBTREEツリー。
1.3.2 B +ツリー構造
B +ツリーはBTREEの変異体である、B +ツリーとB木の差です。
1)N B +ツリーフォークは、Nキーアップ、及びB木n-1個のキーの最大値を有します。
2)B +ツリーのリーフノードは、すべての鍵情報、サイズに応じてキー配列を維持します。
3)全ての非リーフノードは、インデックスのキーの一部として見ることができます。
B +ツリーのリーフノードの保存のみキー情報として、お問い合わせは、任意のキー根の葉から来ています。だから、B +ツリークエリパスは、より安定しています。
1.3.3 MySQLのB +ツリー
古典的なB +ツリーのMySQLのインデックスデータ構造が最適化される。元のB +ツリー隣接するリーフノードへのリストポインタポイントの増加に基づいて、アクセス間隔を向上させるために、B +ツリー順序論理ポインタが形成されていますパフォーマンス。
MySQLは概略構成図B +ツリーインデックスであります
1.4分類インデックス
1)単一値インデックスは:インデックスは、単一の列を含む、テーブルは、複数の個別のインデックスを持つことができます。
2一意のインデックス):列のインデックス値は一意であるが、NULL値を許可する必要があります
3)複合インデックス:インデックスは、複数の列を含みます
1.5構文インデックス
同時に作成することができ、インデックステーブルの作成では、あなたはいつでも新しいインデックスを追加することができます。
環境を準備します
create database demo_01 default charset=utf8mb4;
use demo_01
CREATE TABLE city(
city_id int(11) NOT NULL AUTO_INCREMENT,
city_name varchar(50) NOT NULL,
country_id int(11) NOT NULL,
PRIMARY KEY(city_id)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE country(
country_id int(11) NOT NULL AUTO_INCREMENT,
country_name varchar(100) NOT NULL,
PRIMARY KEY(country_id)
)ENGINE=InnoDB DEFAULT CHARSET=utf8;
insert into city(city_id,city_name,country_id) values(1,'西安',1);
insert into city(city_id,city_name,country_id) values(2,'NewYork',2);
insert into city(city_id,city_name,country_id) values(3,'北京',1);
insert into city(city_id,city_name,country_id) values(4,'上海',1);
insert into country(country_id,country_name) values(1,'China');
insert into country(country_id,country_name) values(2,'America');
insert into country(country_id,country_name) values(3,'Japan');
insert into country(country_id,country_name) values(4,'UK');
1.5.1インデックスの作成
構文:
CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
[USING index_type]
ON tb1_name(index_col_name,...)
index_col_name : column_name[(length)][ASC | DESC]
例:都市テーブルCITY_NAMEフィールドのインデックスを作成します。
create index idx_city_name on city(city_name);
デフォルトでは、主キーインデックスが付属しています):私たちは、次のようにインデックステーブルの変化がある:(注見ることができます
1.5.2ビューのインデックス
構文:
show index from table_name;
ビュー市インデックステーブル
show index from city;
1.5.3インデックスの削除
構文:
DROP INDEX index_name ON tb1_name;
例:削除街にテーブルの上にそうidx_city_name
DROP INDEX idx_city_name on city;
インデックスに関するお問い合わせには:
これは、インデックスが削除されていることがわかりました
1.5.4ALTERコマンド
1) alter table tb_name add primary key(colum_list);
该语句添加一个主键,这意味着索引值必须是唯一的,且不能为null
2) alter table tb_name add unique index_name(column_list);
这条语句创建索引的值必须是唯一的(除了NULL外,NULL可能会出现多次)
3) alter table tb_name add index index_name(column_list);
添加普通索引,索引可能出现多次.
4) alter table tb_name add fulltext index_name(column_list);
该语句指定了FULLTEXT,用于全文索引
1.6設計原理インデックス
インデックスは、より効率的かつ実用的な指標、効率指標を向上させるのは簡単で実用的な、これらの原則に沿ってインデックスを作成するときに考慮しようとすると、いくつかの原則に従うように設計されています。
- クエリの高頻度、およびデータ・テーブル・インデックスの大量。
- 句より、それが最も一般的に使用される、最高のフィルタグループを選択して、列を言わなければならない場所を組み合わせた場合のインデックスフィールドを選択し、列には、where句から最良の候補の抽出条件にする必要があります。
- ユニークインデックス、高い差別、インデックスのより効率的な使用を使用してください。
- インデックスは、効果的にデータクエリの効率を向上させることができますが、インデックスは、より良く、より多くのインデックスは、インデックスのメンテナンスコストが自然増加数ではありません。表の挿入、更新、削除などのDML操作より頻繁に、より多くのインデックスが操作を消費する適切な時間を増加させ、DML操作の効率を低下させ、非常に高い維持費を紹介します。また、あまりにも多くの、そしてインデックス、MySQLの意志最終的にはまだ使用可能なインデックスを見つけますが、有罪眠い疾患を選択しますが、間違いなく選択肢の価格が増加します。
- インデックスが保存ので、I / Oの効率指標のアクセスを強化するためにハードディスクを使用して作成された後の短いインデックスを使用し、それはまた、アクセスの全体的な効率を向上させることができます。全長フィールドは比較的短いインデックスで構成されている場合、インデックス値は、与えられたサイズの複数のメモリブロックに格納することができる効果的に対応するI / Oアクセス効率MySQLを向上させることができます。
- 使用すると、クエリはどこにインデックスの最初のいくつかのフィールドの句は、このクエリのSQLは、複合インデックスを使用できるかどうか複合インデックスは、その後、N指標に相当するものを作成するN列の組み合わせプレフィックスを残しましたクエリの効率を改善します。
-- 创建复合索引:
CREATE INDEX idx_name_email_status on tb_name(Name,email,STATUS);
-- 就相当于
-- 对name 创建索引;
-- 对name,email创建索引;
-- 对name,email,status创建索引;