Mysql公式の元の単語：インデックスは、MySQLが効率的にデータを取得するのに役立つソートされたデータ構造です。
データ構造のウェブサイト：www.cs.usfca.edu
1.インデックスデータ構造：赤黒ツリー、ハッシュ、B +ツリー
インデックスデータ構造：
- 二分木
- 欠点：データスタッキングツリーの片側が表示され、バイナリツリーが単一リンクリストに退化します。
- 赤黒木
- 概念：バイナリバランスツリーとも呼ばれます。ツリーの片側が長すぎると、自動的にバランスが取られます。
- 短所：データ量が比較的多い場合、データ挿入速度が遅くなり、ディスクの読み取りおよび書き込みIOの数が多くなります。
- ハッシュ
- コンセプト：ディスクに散在して不規則に格納されている散在ストレージ構造。
- 短所：ただし、範囲検索を使用する場合（未満よりも大きい）、パフォーマンスは低下します。
- Bツリー
- 概念：
- 葉ノードの深さが同じで、葉ノード間にポインター接続がない
- すべてのインデックス要素が繰り返されていません
- ノード内の要素のインデックスは、左から右に昇順でソートされます
- 概念：
- B +ツリー
- 非リーフノードはデータを格納せず、インデックス（冗長性）のみを格納し、さらに多くのインデックスを配置できます
- リーフノードにはすべてのインデックスフィールドが含まれています
- リーフノードはポインタで接続され、間隔アクセスのパフォーマンスを向上させます
2.インデックスの概念、データベースストレージエンジン
Mysqlインデックス：
第1レベルのインデックスは常駐インデックスであり、メモリ（RAM）に直接格納されます
インデックスデータsqlの単一ノードのデータサイズをクエリします。
show global status like ‘Innodb_page_size’;
Mysqlストレージエンジン：
MyISAMストレージエンジン（非クラスター化インデックス）
テーブルインデックスとテーブルデータは別々に保存されます。インデックスを保存するファイルはMYIで、データを保存するファイルはMYDです。
インデックスリーフノードには、インデックスとデータに対応する物理アドレスが格納されます。これは、非クラスター化インデックスとも呼ばれます。
InnoDBインデックスの実装（クラスター化インデックス）：
-
テーブルデータファイル自体は、B +ツリーで編成されたインデックス構造ファイルです（インデックスとデータは同じファイルにあります）。
-
クラスター化されたインデックスリーフノードには完全なデータレコードが含まれます
-
InnoDBテーブルには主キーが必要であり、整数の自動インクリメント主キーを使用することをお勧めします
（インデックス構造はバイナリツリーの左側を右側よりも小さく保つため、整数の自動インクリメントを使用すると、データの挿入と検索が容易になります）。 -
非主キーインデックス構造、リーフノードは主キー値を格納します（一貫性とストレージスペースの節約）
InnoDBストレージエンジンテーブルが主キーを作成しない場合、最下層はテーブルの列を主キーとして選択します。適切な列（一意）が見つからない場合、非表示の列が主キーとして作成されます。
3.結合インデックスの基礎となるデータ構造と左端のプレフィックスの最適化の原則
ジョイントインデックス（複合インデックス）：
基礎となるストレージ構造：複数のフィールドが使用される場合、最初のフィールドがソートに使用されます。最初のフィールドが同じでソートできない場合、2番目のフィールドが使用され、各レベルで左から右に増加するB + TREEが実現されます。原則として。
左端の接頭辞の最適化は、結合インデックスに使用されます。
クエリ時：条件の最初のフィールドで複合インデックスが使用されていない場合、インデックスは使用されません。2番目または3番目のフィールドを見ると、テーブル全体が故障していて、インデックスを使用して検索できないためです。
上記のように、クエリ条件で「10002」を使用しない場合、結合インデックスは使用されません。
4. Mysqlインデックス最適化の軍事規制
ネットワークデータを抽出する~~~
（1）中核的な軍事規制
（1）データベースで操作を行わない：CPU計算をビジネスレイヤーに移動する必要があります
（2）単一テーブルのデータ量を制御する：単一テーブルレコードは1000wで制御されます
（3）制御列番号：フィールド数は20以内で制御されます
（ 4）パラダイムと冗長性のバランスをとる：効率を向上させるために、パラダイム設計と冗長データを犠牲にする
（5）拒否3B：大きなSQL、大きなもの、大量の拒否
（2）現地の軍事規制
（6）数値型
tinyint（1Byte）
smallint（2Byte）
mediumint（3Byte）
int
（4Byte ）bigint（8Byte ）をうまく活用する
悪い例：int（1）/ int（11）
（7）文字を数値に変換する
char（15）の代わりにintを使用してIPを保存します
（8）enumを使用するか、最初に設定
します。例：sexenum（ 'F'、 'M'）
（9）NULLフィールドの使用を回避し
ます。NULLフィールドは
、NULLフィールドのインデックスを照会および最適化することが困難です。追加のスペースが必要
です。NULLフィールドの複合インデックスは無効です。不正
なケース：
namechar（32）デフォルトnull
ageint not null
良いケース：
ageint not nullデフォルト0
（10）text / blob
varcharのパフォーマンスの使用量はtext よりもはるかに高くなります。blobは
本当に避けられないので、テーブルを分解してください
（11）画像をデータベースに保存しないでください。説明する必要がありますか？
（3）軍事規制の索引付け
（12）慎重にそして合理的にインデックスを使用してください。
クエリを改善し、更新を遅くしてください。
インデックスはできるだけ多くしてはいけません（インデックスを追加する必要がない場合は追加する必要があります）
。「gender」など、インデックス作成に適さないカバーレコードが多すぎます。
（13）文字フィールドには接頭辞インデックスを作成する必要があります
（14）インデックスで列操作を実行しない
場合の悪いケース：
select id where age +1 = 10;
（15）Innodb主キーは、自動インクリメント
列（SK：ブロガーによる承認なし）主キーを使用してクラスター化インデックスを構築することを推奨します。
主キーは変更し
ないでください。文字列は主キーとして使用しないでください主キー
が指定されていない場合、innodbは代わりに一意の非nullインデックスを使用します
（16）外部キー
はありません。プログラム保証に拘束されます
（4）SQL軍事規制
（17）SQLステートメントはできるだけ単純です
。1つのSQLは1つのCPUでのみ操作
できます。大きなステートメントは小さなステートメントを分割してロック時間を短縮
できます。1つの大きなSQLはライブラリ全体をブロックできます
（18）簡単な事柄
取引時間は可能な限り短い
悪い場合：
画像取引のアップロード
（19）代わりにクライアントプログラム
なしで、trig / func トリガーおよび関数の使用を避け
ます
（20）*
CPU、IO、メモリ、帯域幅の消費を選択する必要はありません。
このプログラムはスケーラブルではありません
（21）ORをIN（）
に書き換える効率、または
メッセージがレベルn
である場合のメッセージのlog（n）レベルの数は
、phone = '159'またはphone = '136'のtから200の選択ID 内で制御することが推奨されます。
=>
tからidを選択し、電話番号を入力します（ '159'、 '136'）;
（22）UNION
mysqlインデックスマージが非常に精神的に遅滞している
ため、ORは書き直されます。ここで、phone = '159'またはname = 'john';
=>
select id from t where phone = '159'
union
select id from t where name = 「ジョン」
（23）マイナス％を避ける
（24）注意してcount（*）を使用してください
（25）上記と同じ
（26）効率的なページング
制限の制限が高いほど、効率は低くなり
ます。tからのIDの選択10000、10;
=>
tからIDを選択ここで、ID> 10000制限10;
（27）unionの代わりにunion allを使用すると、
重複排除のオーバーヘッドが発生します
（28）結合を減らす
（29）group byを使用して
グループ化し、
自動的にソートする
（30）同じ型の比較を使用してください
（31）ロードデータを使用してデータをガイドする
ロードデータは、挿入よりも約20倍高速です。
（32）バッチ更新を分割する
（33）新能分析工具
show profile;
mysqlsla;
mysqldumpslow;
説明する;
遅いログを表示します。
プロセスリストを表示します。
query_response_time（percona）を示して下さい