MySQLのインデックスの理由と利点と欠点を提案

1 Star2 Stars3 Stars4 Stars5 Stars (まだ評価されていません)
Loading...

インデックス作成の利点と欠点:

なぜインデックスを作成するのですか?

これは、索引を作成するとシステムのパフォーマンスが大幅に向上するためです。
まず、ユニークなインデックスを作成することで、 データベーステーブル内の各データ行の一意性を保証できます。
第2に、索引を作成する主な理由であるデータの検索を大幅に高速化できます。
第3に、特にデータの参照整合性を達成する観点から、テーブルとテーブルの間の接続を高速化できます。
第4に、データ検索にグループ化とソート句を使用すると、クエリ内のグループ化とソートの時間を大幅に短縮することができます。
第5に、索引を使用することによって、照会の過程で最適化hiderを使用して、システムのパフォーマンスを向上させることができます。

誰かが質問するかもしれません:インデックスを追加することには非常に多くの利点があります。テーブルの各列のインデックスを作成しないでください。 このようなアイデアは合理性を持っていますが、その片側性もあります。 索引付けには多くの利点がありますが、表の各列に索引を追加することは賢明ではありません。

これは、インデックスを追加することには多くの欠点があるためです。

まず、インデックスを作成してインデックスを維持するには時間がかかります。インデックスはデータの量が増えるにつれて増加します。

第2に、索引は物理空間を占有する必要があります。データ・スペースを占有するデータ表に加えて、各索引も一定の物理空間を占有します。 クラスタード・インデックスを構築する場合は、より多くのスペースが必要です。

第3に、表のデータを追加、削除、および変更するときに、索引も動的に維持され、データの保守速度が低下します。

インデックスを作成するのに適したフィールドの種類:

索引は、データベース表の特定の列の上に構築されます。 したがって、索引を作成するときは、どの列をどの列に作成できるか、どの列で索引を作成できないかを慎重に検討する必要があります。

一般的に、これらの列には次のような索引を作成する必要があります。

まず、検索が必要な列で検索を高速化できます。

第2に、主キーとしての列では、列の一意性と組織表内のデータの配置が強制されます。

第3に、接続で頻繁に使用される列では、これらの列は主に外部キーであり、接続を高速化できます。

第4に、索引がソートされ、指定された範囲が連続しているため、スコープに従って検索する必要のある列で索引を作成します。

第5に、索引がソートされているため、索引のソートを使用してソート照会時間を短縮できるように、頻繁にソートする必要がある索引を列に作成します。

第6に、WHERE節で頻繁に使用される列の索引を作成して、条件の判断を高速化します。

たとえば、selectの条件はf1とf2であり、フィールドf1またはフィールドf2にレジュームインデックスがある場合、フィールドf1およびf2のみでは無用です。役に立った。

インデックスの作成に適していないフィールドの種類:

この場合も、一部の列に対して索引を作成しないでください。 一般に、索引付けすべきではないこれらの列には、次の特性があります。

まず、ほとんど使用されていない、または照会で参照されている列に対して索引を作成しないでください。 これは、これらの列はめったに使用されないため、索引が存在するか索引がないためです。

クエリの速度は向上しません。 逆に、指標の増加により、システムのメンテナンス速度が低下し、必要なスペースが増加する。
次に、データ値の少ない列に対してはインデックスを追加しないでください。 これは、これらの列にはpersonnel表のgender列などの値がほとんどないため、

問合せの結果では、結果セットのデータ行は表のデータ行の大部分を占めます。つまり、表で検索する必要があるデータ行の割合が大きくなります。

索引を増やしても、検索が大幅に高速化されるわけではありません。
第3に、テキスト、イメージ、およびビットデータ型として定義された列にインデックスを追加しないでください。 これは、これらの列のデータ量が非常に大きいか、または非常に小さいためです。
第4に、変更のパフォーマンスが検索パフォーマンスよりもはるかに高い場合、インデックスを作成すべきではありません。 これは、パフォーマンスと検索パフォーマンスの変更が矛盾するためです。

索引を増やすと、検索パフォーマンスは向上しますが、変更パフォーマンスは低下します。 索引が減少すると、修正性能が改善され、検索性能が低下する。

したがって、変更のパフォーマンスが検索パフォーマンスよりもはるかに高い場合は、索引を作成しないでください。

インデックスを作成する方法:

1、create index <インデックスの名前>などのインデックスをtable_name(カラムのリスト)に作成します。
2、alter table table_nameなどのテーブルを変更する[インデックスの名前](カラムのリスト);
3、create table table_name([…]、INDEX [インデックスの名前](列のリスト))など、テーブルの作成時にインデックスを指定します。

テーブル内のインデックスのメソッドを表示する:

テーブル名からインデックスを表示;インデックスを表示

索引タイプと作成例:

1.PRIMARY KEY(主キー索引)

MySQL > alter table
Table_name主キーの追加( `column`)

2.UNIQUEまたはUNIQUE KEY(ユニークインデックス)

mysql> alter table table_name unique( `column`)を追加する

3.フルテキスト(全文索引)
Mysql> alter table table_name全文を追加する( `column`)

4.INDEX(一般指標)
Mysql> alter table table_nameインデックスを追加index_name( `column`)

5.複数列インデックス(クラスター化インデックス)
Mysql> alter table `table_name`インデックスを追加index_name(` column1`、 `column2`、` column3`)

1。 ユニークインデックスを選択

一意索引の値は一意であり、レコードをより迅速に判別するために使用できます。 たとえば、学生テーブルのセカンダリ番号は一意のフィールドです。 この分野のユニークなインデックスを確立することで、学生の情報を迅速に判断できます。 名前を使用すると、同じ名前の現象が発生し、クエリが遅くなる可能性があります。

2。 ソート、グループ化、およびフェデレーションがしばしば必要なフィールドのインデックス作成

並べ替え操作では、ORDER BY、GROUP BY、DISTINCT、およびUNIONなどのフィールドが必要なときに多くの時間を費やす可能性があります。 インデックスを作成すると、ソートを効果的に避けることができます。

3。 クエリ条件として頻繁に使用されるインデックスフィールド

フィールドがクエリ条件としてよく使用される場合、フィールドのクエリ速度はテーブル全体のクエリ速度に影響します。 したがって、このようなフィールドを索引付けすると、表全体の照会速度が向上します。

4。 インデックスの数を制限する

索引の数はできるだけ良くない。 各索引はディスク・スペースを占有する必要があります。索引が増えるほど、より多くのディスク・スペースが必要になります。 リファクタリングとインデックスの更新は、テーブルを変更するときに煩雑です。 索引が多いほど、表の更新に要する時間が長くなります。

5。 少量のデータでインデックスを使用するようにしてください

インデックスの値が長い場合は、クエリの速度に影響します。 たとえば、CHAR(100)型フィールドの全文検索では、CHAR(10)型フィールドよりも時間がかかる必要があります。

6。 プレフィックスを使用してインデックスを作成する

インデックスフィールドの値が長い場合は、値の接頭辞を付けて索引付けすることをお薦めします。 たとえば、TEXTおよびBLOGタイプのフィールドは、フルテキスト検索の時間を無駄にする可能性があります。 フィールドの前に少数の文字しか検索しないと、検索が高速化されます。

7。 使用されていないか、まれに使用されていないインデックスを削除する

テーブル内のデータが大量に更新された後、またはデータの使用が変更された場合、元のインデックスのいくつかはもはや必要ではないかもしれません。 データベース管理者は、これらの索引を定期的に識別して削除して、索引による更新操作への影響を減らす必要があります。

最も左の接頭辞の一致の原理は、非常に重要な原則です。

1 = ""と "" = "" b = "2" c = ""> 3やd = 4のような範囲クエリ(>、<、between、like)が発生するまで、 MySQLは常に右に一致します(a、b、c、d)の索引を作成し、dを索引付けに使用せず、(a、b、d、c)の索引が確立されている場合、a、b、dの順序は任意です。調整。

9。=とinは順不同である可能性があります。

たとえば、a = 1、b = 2、c = 3のcreate(a、b、c)インデックスは任意の順序で指定できますが、 mysqlクエリオプティマイザは、

10.差別度の高い列を索引として選択してください。

差異の数式はcount(distinct col)/ count(*)です。これはフィールドが繰り返されないことを意味します。比率が大きいほど、スキャンするレコードの数が少なくなります。一意のキーは1であり、州および性別フィールドはビッグデータの顔の違いは0です。誰かが質問するかもしれませんが、この比率の経験値は何ですか? この値は、使用シナリオに応じて決定することも難しく、一般的に、結合する必要があるフィールドは、1スキャン以上、つまり10スキャンの平均値が0.1以上である必要があります。

11.インデックス列は計算に参加できず、列を「クリーン」に保ちます。

たとえば、from_unixtime(create_time)= '2014-05-29'は索引を使用できません。理由は非常に簡単です。b +ツリーはフィールド値をデータ表に格納しますが、検索するときはすべての関数を関数に適用する必要があります。比較は明らかにコストがかかります。 したがって、文はcreate_time = unix_timestamp( '2014-05-29')と書かれていなければなりません。

12.できるだけ索引を展開し、新しい索引を作成しないでください。
たとえば、すでにテーブルにインデックスがある場合は、(a、b)のインデックスを追加する必要があります。元のインデックスのみを変更する必要があります。

注:索引を選択する最終的な目標は、照会を高速化することです。 上記の原則は最も基本的な基準ですが、上記のガイドラインに従うことはできません。 読者は将来の勉強や仕事を続けなければなりません。 アプリケーションの実際の状況に応じて分析し、判断し、最適な索引付け方法を選択します。


1 Star2 Stars3 Stars4 Stars5 Stars (まだ評価されていません)
Loading...
      この投稿は審査処理中  | 元のサイトへ