ワン：概要
- 私は、メールボックスのニーズを持っていることは、ログインする必要があることです
- 電子メール= 'XXX' SUSERからMySQLの>を選択F1、F2。
- 私たちは、インデックスがメールにされていない場合は、全表スキャンを取るだろう、ということを知っています。
- だから、私たちは確立するには、2つの方法があります
- MySQLの>テーブルsuserのALTERインデックスindex1と、（メールで）追加; //共通のインデックス
- MySQLの>テーブルsuserの（。電子メールで（6））インデックスのALTER INDEX2を追加; //プリフィックス索引
2：通常のインデックスと接頭辞のインデックスの違いは？
- 私たちはそれらを参照してください、彼らはインデックスツリーの違いが何であるかを確立します
- 
- あなたがチャートから見ることができるように
- （6）各メールボックスの電子メールフィールドのこのインデックス構造は最初の6バイト取るに起因する（すなわち：zhangsを）ので、フットプリントが小さくなります、これはインデックスの接頭辞を使用することの利点があります。
3：一般的なインデックスとインデックスのクエリは異なるプロセスを接頭辞？
- 例
- ID、名前、email='[email protected]「SUSERからのメールを選択します。
- 一般的なインデックス
- インデックスツリーからID2の値を取得するために、このレコードのインデックス値を満たす「[email protected]」を見つけるために、
- 主キー値が行ID2のプライマリ・キーで発見された、電子メール決意値が正しいことを、これらの行は、結果セットを追加しました。
- 次のレコードのインデックスツリーを取るだけの場所を発見し、条件がループ終了の満足email='[email protected]」していました。
- このプロセス、システムだけが唯一の思考の行をスキャンして、プライマリキーインデックスデータに1を取る必要があります。
- プレフィックスインデックス
- インデックス・ツリーのインデックス値が「zhangs」レコードを満たすために発見され、最初に見つかったがIDLです。
- 主キー値が行ID1の主キーで発見された、電子メール値が「[email protected]」、廃棄する行ないと判断しました。
- だけ見つかった場所に次のレコードに取ることは、依然として「zhangs」で取らID2、その後、行インデックスIDが決定される。この値は、結果セットこれらの行の追加を丸めます。
- 値が「zhangs」、サイクルの終わりにアクセス可能でなくなるまで、前の手順を繰り返します。
- プロセスでは、主キーインデックスに戻ると、4回の4行をスキャンされたデータを、取ります。
- 結論
-この比較を通して、あなたは簡単に見つけることができます使用プリフィックス索引を、クエリが読み込まれたデータの数が多くなる可能性があります。
4：差別
-上記の試験を通じて、我々は知っている、それは、増加した問い合わせにつながるの主に基づいて、プリフィックス索引選択の区別を。
- SELECT COUNT（DISTINCT LEFT（column_nameに、$の長さ））/ COUNT（*）FROM table_nameの。//查询区分度
5： インデックスでカバーされたインデックスのプレフィックスへの影響
- インデックスが使用中でカバーできない、プリフィックス索引を使用した後、クエリの顔を、あなたはあり手術台に復帰する必要があります。
6：文字列の顔は、我々はまた、保存するための他の方法を取ることができます
- ハッシュ
- ビットのビット
- 逆
- など