mysqlでは、インデックスはハッシュインデックスとbtreeインデックスの2種類に分けられます。
B-treeインデックスはどのような状況で使用できますか?
1.完全な値の一致インデックス
例:
注文ID="123"
2. 左端のプレフィックスインデックスクエリに一致します
例: ユーザー ID フィールドと日付フィールドに結合インデックスを作成します。
次に、条件として userId を入力すると、そのユーザー ID をインデックスで使用できます。日付を条件として直接入力した場合、インデックスは使用できません。
3. 列プレフィックスクエリの一致
例: order_sn like ‘134%’ これはインデックスを使用できます。
4. 範囲値のクエリ
createTime>'2015-01-09' および createTime<'2015-01-10'
5. 左前の列と完全に一致し、別の列と範囲が一致します
例:
userId=1 および createTime>'2016-9-18'
6. インデックスのみにアクセスするクエリはカバリングインデックスと呼ばれ、インデックスにはクエリカラムのデータが含まれます。
BTREEインデックスの制限事項
1. インデックスの左端の列から検索しないと、そのインデックスは使用できません。
たとえば、ジョイントインデックスを作成します:
orderId フィールドと createTime フィールドは、orderid の条件を指定せずに createTIME の条件のみを入力した場合、このインデックスは使用されません。
2. インデックスを使用する場合、インデックス付きの列をスキップすることはできません。
3つの列:
日付、名前、電話番号が列とインデックスを形成します。クエリ時に日付と電話番号のみを入力した場合は、フィルタリングのインデックスとしてのみ使用できます。
3.NOT IN および <> 操作ではインデックスを使用できません。
4. クエリ内の特定の列に範囲クエリがある場合、その右側のすべての列はインデックスを使用できません。
ハッシュインデックスの特徴
ハッシュ インデックスはハッシュ テーブルに基づいて実装されます。ハッシュ インデックスは、クエリ条件がハッシュ インデックス内のすべての列に正確に一致する場合にのみ使用できます。同等のクエリのみにすることができます。
ハッシュ インデックス内のすべての列について、ストレージ エンジンは各行のハッシュ コードを計算し、ハッシュ コードはハッシュ インデックスに保存されます。
制限事項:
1. 2 回読み取る必要があります。最初にハッシュを読み取り、対応する行を見つけてから、対応する行データを読み取ります。
2.ハッシュインデックスはソートに使用できません。
3. 正確な検索のみがサポートされており、部分的なインデックス検索はサポートされておらず、範囲検索もサポートされていません。
ハッシュの競合:
ハッシュ インデックスは選択性の低いフィールドには使用できませんが、選択性が強い列にハッシュ インデックスを作成するには使用する必要があります。
例: 性別フィールドにハッシュ インデックスを作成しないでください。
なぜインデックスを使用するのですか?
1. インデックスにより、ストレージ エンジンがスキャンする必要があるデータの量が大幅に削減されます。インデックスがデータサイズより小さいです。
2. インデックスは、一時テーブルの使用を避けるための並べ替えに役立ちます。インデックスは順序付けされています。
3. インデックスはランダム I/0 をシーケンシャル IO に変換できます
インデックスは多ければ多いほど良いのでしょうか?
1. インデックスにより書き込み操作のコストが増加します
2. インデックスが多すぎると、クエリ オプティマイザーと選択時間が増加します。
インデックス作成の戦略
1. インデックス列では式や関数を使用できません
例: select * from product where to_days(out_date) –to_days(current_date)<=30、out_date はインデックス列です。
次のように変更されました:
out_date
2.インデックスサイズは特定の値を超えることはできません。
inodb インデックス列のサイズは長さ 200 です。
3. プレフィックス列とインデックス列の選択性。
テーブル (アカウント) にインデックス idx_NAME を作成します;
4. ユニオンインデックス
インデックス列の順序を選択する方法。
1. 頻繁にインデックスが付けられる列。
2. 選択性の高いカラムが優先されます。
3. 小さな列にインデックスを作成します。