MySQLインデックスに関する知識点をまとめました
3029 ワード
ブログの移行:http://cui.zhbor.com/article/14.html
MySQLインデックスは、多くのことを学ぶ必要がありますが、私はいくつかの自分の総括を书くことができます.これらの総括は主に普段実际のプロジェクトで运用されています.多くの経験があるので、表を设计する人はよく知っていますが、いつも「これはどこで使ってもいいし、プラスしてもいいし、デザインしても大丈夫です」とあります.このような考えは、無責任だ.インデックスに関する理論的なものも多く奥深く、私にも分からないところがたくさんあるので、みんなを誤解しないように理論的なものをたくさん書くことはありません.
一、まずインデックスとは何か
公式の説明:データベースシステムは、特定の検索アルゴリズムを満たすデータ構造を維持しており、これらのデータ構造は何らかの方法でデータを参照(指向)し、これらのデータ構造上で高度な検索アルゴリズムを実現することができる.このデータ構造は、インデックスです.
MySQLは一般的にB+Treeを使用してインデックス構造を実現していますが、B+Treeが何なのか悩む必要はありません.実は辞書のディレクトリのようです.
二、インデックスが解決した問題
次の表に基づいて実験を行います.
インデックスは、データファイルから分離された個別のファイルであり、より良いデータ構造を有し、ファイルがより小さい.
インデックスの役割は、上から読むか下から読むかをすばやく位置決めし、順番を決めるリストです.例えば、上記の表では、性別が男性2クラスのデータを取得するには、sex+classの連合インデックスscindexを確立すると、インデックスファイルからデータアドレスを迅速に取得し、データファイルからコンテンツを取得することができます.以下のようにします.
1
実は、インデックスもコンテンツを格納することができて、データファイルにアクセスする必要がなくて、スピードはとても速くて、これは‘カバーインデックス(Covering Index)’で、出力したEXtra情報の中でUsing indexを出力して、カバーインデックス(あなたのselectフィールドがインデックスの中にあることを前提とします)を使います.たとえば、検索したデータは次のようになります.
explainには、sql文がスキャンしたローの数です.インデックスを追加する目的は、ローの数を減らすことです.
注意:1回の検索では1つのインデックスしか使用できません.使用しているインデックスが望ましくない場合は、force indexを使用してsql文に指定したインデックスを強制的に使用することができます.
まとめ:インデックスは、コンテンツへの迅速な位置決め、並べ替えの迅速な完了、データファイルの読み取りを必要とせずにデータを返すことができます.
三、注意すべき問題
1、コアのsql文は必ずインデックスを追加し、ステータスタイプフィールドはインデックスを追加しないほうがいい.
2、文字フィールドのインデックスインデックスインデックスインデックスを追加する場合は、プレフィックスインデックスを考慮します.
MySQL接頭辞インデックスは、インデックスファイルのサイズを効果的に小さくし、インデックスの速度を向上させることができます.しかし、接頭辞インデックスにもデメリットがあります.MySQLはORDER BYやGROUP BYで接頭辞インデックスを使用することはできません.また、カバーインデックス(Covering Index)として使用することはできません.構文:
ALTER TABLE table_name ADD KEY(column_name(prefix_length));
prefix_lengthという値は、何個のレコードを区別するかを示しています.例えば、この値が5であれば、26 x 26 x 26 x 26 x 26 x 26 x 26 x 26 x 26データを区別することができます.
3、sql文の中で演算をしないで、演算はプログラムの中で行います.
4、文字列を主キーにしない
私のデータベースはMariaDBです.デフォルトのエンジンはInnoDBです.テーブルにプライマリ・キー・インデックスがある場合、InnoDBはプライマリ・キーにクラスタ・インデックスを作成します(クラスタ・インデックスはすべてのエンジンでサポートされているわけではありません.現在はInnoDBサポートです).テーブルにプライマリ・キー・インデックスがない場合、InnoDBは非表示のプライマリ・キーを定義してクラスタ・インデックスを作成します.テーブルにはクラスタ・インデックスが1つしかありません.文字列をプライマリ・キーにしない理由については、いくつかの理由を探しました.
通常、DBMS(データベース管理システム)はプライマリ・キーに集約インデックスを作成します.通常、B-Treeのデータ構造を使用してインデックス・データを格納するため、プライマリ・キーには次の2つの要件があります.が短いほど良い--1つのPageに格納されているノードが短いほど、検索速度が速くなります. は順次増加します.挿入された各データのプライマリ・キーが前のプライマリ・キーより大きい場合、B-Tree上のノードも順次増加し、頻繁なB-Tree分割は発生しません.
短いほどクエリーの速度が速くなり、順次増加するのは挿入の速度が速いためです.
この2つの要件があり、各データ型を分析します.
文字タイプ:前述した2つの要件をほとんど満たしていません.文字タイプは一般的に短くはありません.また、順番に増加するわけではないため、特に推奨されるプライマリ・キー・タイプではありません.もちろん、ビジネスで文字タイプを使用する必要がある場合は、varchar(XX)ではなくchar(XX)を使用します.
数値タイプ:詳細は不要
原文住所:http://cui.zhbor.com/article/14.html
転載先:https://www.cnblogs.com/hongbo819/p/4871945.html
MySQLインデックスは、多くのことを学ぶ必要がありますが、私はいくつかの自分の総括を书くことができます.これらの総括は主に普段実际のプロジェクトで运用されています.多くの経験があるので、表を设计する人はよく知っていますが、いつも「これはどこで使ってもいいし、プラスしてもいいし、デザインしても大丈夫です」とあります.このような考えは、無責任だ.インデックスに関する理論的なものも多く奥深く、私にも分からないところがたくさんあるので、みんなを誤解しないように理論的なものをたくさん書くことはありません.
一、まずインデックスとは何か
公式の説明:データベースシステムは、特定の検索アルゴリズムを満たすデータ構造を維持しており、これらのデータ構造は何らかの方法でデータを参照(指向)し、これらのデータ構造上で高度な検索アルゴリズムを実現することができる.このデータ構造は、インデックスです.
MySQLは一般的にB+Treeを使用してインデックス構造を実現していますが、B+Treeが何なのか悩む必要はありません.実は辞書のディレクトリのようです.
二、インデックスが解決した問題
次の表に基づいて実験を行います.
インデックスは、データファイルから分離された個別のファイルであり、より良いデータ構造を有し、ファイルがより小さい.
インデックスの役割は、上から読むか下から読むかをすばやく位置決めし、順番を決めるリストです.例えば、上記の表では、性別が男性2クラスのデータを取得するには、sex+classの連合インデックスscindexを確立すると、インデックスファイルからデータアドレスを迅速に取得し、データファイルからコンテンツを取得することができます.以下のようにします.
1
explain SELECT * FROM `stu_test` where sex= ' ' and class= ' ' ; 実は、インデックスもコンテンツを格納することができて、データファイルにアクセスする必要がなくて、スピードはとても速くて、これは‘カバーインデックス(Covering Index)’で、出力したEXtra情報の中でUsing indexを出力して、カバーインデックス(あなたのselectフィールドがインデックスの中にあることを前提とします)を使います.たとえば、検索したデータは次のようになります.
explainには、sql文がスキャンしたローの数です.インデックスを追加する目的は、ローの数を減らすことです.
注意:1回の検索では1つのインデックスしか使用できません.使用しているインデックスが望ましくない場合は、force indexを使用してsql文に指定したインデックスを強制的に使用することができます.
まとめ:インデックスは、コンテンツへの迅速な位置決め、並べ替えの迅速な完了、データファイルの読み取りを必要とせずにデータを返すことができます.
三、注意すべき問題
1、コアのsql文は必ずインデックスを追加し、ステータスタイプフィールドはインデックスを追加しないほうがいい.
2、文字フィールドのインデックスインデックスインデックスインデックスを追加する場合は、プレフィックスインデックスを考慮します.
MySQL接頭辞インデックスは、インデックスファイルのサイズを効果的に小さくし、インデックスの速度を向上させることができます.しかし、接頭辞インデックスにもデメリットがあります.MySQLはORDER BYやGROUP BYで接頭辞インデックスを使用することはできません.また、カバーインデックス(Covering Index)として使用することはできません.構文:
ALTER TABLE table_name ADD KEY(column_name(prefix_length));
prefix_lengthという値は、何個のレコードを区別するかを示しています.例えば、この値が5であれば、26 x 26 x 26 x 26 x 26 x 26 x 26 x 26 x 26データを区別することができます.
3、sql文の中で演算をしないで、演算はプログラムの中で行います.
4、文字列を主キーにしない
私のデータベースはMariaDBです.デフォルトのエンジンはInnoDBです.テーブルにプライマリ・キー・インデックスがある場合、InnoDBはプライマリ・キーにクラスタ・インデックスを作成します(クラスタ・インデックスはすべてのエンジンでサポートされているわけではありません.現在はInnoDBサポートです).テーブルにプライマリ・キー・インデックスがない場合、InnoDBは非表示のプライマリ・キーを定義してクラスタ・インデックスを作成します.テーブルにはクラスタ・インデックスが1つしかありません.文字列をプライマリ・キーにしない理由については、いくつかの理由を探しました.
通常、DBMS(データベース管理システム)はプライマリ・キーに集約インデックスを作成します.通常、B-Treeのデータ構造を使用してインデックス・データを格納するため、プライマリ・キーには次の2つの要件があります.
短いほどクエリーの速度が速くなり、順次増加するのは挿入の速度が速いためです.
この2つの要件があり、各データ型を分析します.
文字タイプ:前述した2つの要件をほとんど満たしていません.文字タイプは一般的に短くはありません.また、順番に増加するわけではないため、特に推奨されるプライマリ・キー・タイプではありません.もちろん、ビジネスで文字タイプを使用する必要がある場合は、varchar(XX)ではなくchar(XX)を使用します.
数値タイプ:詳細は不要
原文住所:http://cui.zhbor.com/article/14.html
転載先:https://www.cnblogs.com/hongbo819/p/4871945.html