データベースインデックス(メモ)

引用する
最も簡単なデータクエリー方式は、全テーブルスキャンで、条件に合ったデータを見つけることです.
インデックスのデザインのインスピレーションは辞書に由来し、重要な情報に基づいて迅速に位置決めできます.
インデックスを使用する理由
インデックスは、全テーブルスキャンを回避し、検索効率を向上させることができます.
どのような情報がインデックスになるか
プライマリ・キー、ユニーク・キーなど、データに一定の区分度を持たせることができるフィールド.
インデックスのデータ構造
主流はB+ツリーを使用し、一部のデータベースインデックスはHashインデックス、BitMapを使用する.
Hashインデックスの欠点

Hashインデックスは=とINクエリーのみを満たすことができ、範囲クエリーは実現できません.

Hashインデックス値のサイズ関係は、必ずしもHash演算前のサイズ関係と同じではなく、データベースはインデックスのデータを利用してソート演算を回避することはできません.

コンポジットインデックスについて、Hashインデックスは、Hash値を計算する際にコンポジットインデックスキーが結合された後にHash値を一緒に計算するものであり、Hash値を単独で計算するものではないので、部分インデックスキーでクエリすることはできない.

異なるデータには同じHash値が存在する可能性があるため、テーブルスキャンは避けられない.

大量のHash値が等しい場合、性能は低下します.

密インデックスと疎インデックスの違い
≪密インデックス|Sensity Index|emdw≫:リーフ・ノードにはデータ・レコード全体が保存されます.密インデックスはテーブルの物理的な順序を決定し、1つのテーブルには1つの物理的な順序しかないため、1つのテーブルには1つの密インデックスしか作成できません.
疎インデックス:リーフノードには、キー値とローデータレコードのアドレス/プライマリキーのみが保存されます.
InnoDB
プライマリ・キーが定義されている場合、プライマリ・キーは密なインデックスとして使用されます.
プライマリ・キーが定義されていない場合、テーブルの最初の一意の空でないインデックスは密なインデックスとして使用されます.
以上の条件を満たさないと、InnoDBの内部に非表示のプライマリ・キー(密なインデックス)が生成されます.
非プライマリ・キー・インデックスは、関連するキー・ビットと対応するプライマリ・キー値を格納し、2回の検索を含む.
MySQL InnoDBでは、プライマリ・キーは密インデックスを使用し、セカンダリ・キーは疎インデックスを使用します.疎インデックスには、データのプライマリ・キーが格納されます.MyISAMでは、プライマリ・キーとセカンダリ・キーの両方が疎インデックスであり、データのアドレスが格納されている.
遅いクエリSQLの位置決めと最適化方法
全体的な考え方:

スローログに従ってスロークエリーSQL

を位置決めする

explain等のツールを用いてSQL

を分析する.

SQLを修正するか、SQLをできるだけインデックス

に移動させる.
スロー・ログ:MySQLのスロー・クエリー・ログは、MySQLによって提供されるログ・レコードであり、MySQLにおける応答時間がバルブ値を超える文を記録するために使用される.
設定:
キー
コンフィギュレーション
説明
long_query_time
1
1 sを超えると遅いクエリーとして記録されます
slow_query_log
ON
スロー・クエリー・ログを開く
slow_query_log_file
xxx.log
スロー・クエリー・ログ・ファイル
連合インデックスの最左マッチング原則の成因
結合インデックスの作成:index_area_title.SELECT * FROM person_info WHERE area = 'TIANJIN' AND title = 'YUNZHI'、インデックスを移動します.順序を乱すことができる.SELECT * FROM person_info WHERE area = 'TIANJIN'、インデックスを移動します.
しかし、SELECT * FROM person_info WHERE title = 'YUNZHI'は、インデックスを移動しません.

MySQLは、範囲クエリ(>/ 。 a = 3 and b = 4 and c > 5 and d = 6に するまで に し、(a, b, c, d)の のインデックスが されると、dはインデックスを できません.(a, b, d, c)のインデックスが された に できます.

=およびINは、 を すことができ、 えばa = 1 and b = 2 and c = 3が(a, b, c)インデックスを するのは の であり、MySQLのクエリー・オプティマイザは、インデックスが できる に される.

の となるMySQL インデックスを するルールは、まず インデックスの 、つまりインデックスの のフィールドをソートし、 のフィールドに づいて、インデックスの のフィールドをソートすることです.
1 のフィールドは であり、2 のフィールドは であるため、2 のフィールドを してインデックスが されないと します.
インデックスは ければ いほど いですか?

データ の さいテーブルでは、インデックスを する はありません. すると、 のオーバーヘッドが します.

データ では、インデックスを する があるため、より くのインデックスは、より くのメンテナンスコストを します.

より くのインデックスは、より くの を します.