PHPのインタビューのトピック--- 16、MySQLは、高性能指数テストサイトを作成
概要
文の要約：
注：書き込み専用のブティック
1、インデックスベース？
同様の図書カタログ：ディレクトリに似た図書のインデックスは、書籍の特定のトピックを見つけるために、あなたが本のディレクトリを見つける必要があり、対応するページ番号を配置します
索引 - >行番号 - >データ：対応する値を検索し、データの対応する行を検索するために索引に行くデータクエリのための同様の方法で使用されるストレージエンジンがインデックスに一致します
2、インデックスのパフォーマンスへの影響？
1、大幅に大幅にクエリの速度を向上させ、ディスクの書き込み速度をアップ削減、サーバーをスキャンする必要があるデータの量を削減
2は、サーバーのヘルプは、ソートや一時テーブルを避けます
3、ランダムI / Oは、シーケンシャルI / Oとなり
3、非常に小さなテーブル、など50件のデータ、インデックス、高速全表スキャンまたは高速？
より高速な全表スキャン：そのため、クエリのインデックスステップの非常に多段階とても遅いです
4、インデックスの使用シナリオ？
小さなテーブルのフルテーブルには、高効率をスキャン：非常に小さなテーブルでは、完全なテーブルは、ほとんどの場合、より高い効率をスキャン
非常に効果的な大きなテーブルへのミディアム：インデックスは非常に有効です
大きなテーブル+パーティションインデックス：建物のコストとインデックスを使用しては、その後にパーティションを解決するための技術を使用することができ、成長します
図5に示すように、インデックス（ベース）のタイプ？
一般的なインデックス：非常に一般的なインデックス：最も基本的なインデックス、制約なし
唯一のインデックス：ユニーク制約：ノーマルインデックスに似ていますが、ユニーク制約と
プライマリキーインデックス：一意性制約NOT NULL +：特別な一意のインデックスは、NULL値を許可していません。
インデックスには多くの種類がありますが、ストレージエンジン層に実装されている
非常に一般的なインデックス：基本的なインデックス、制約のない通常のインデックス
ユニークインデックス：一意性制約：通常のインデックスに似てますが、ユニーク制約持つ
主キー索引を：+ユニーク制約が空で許可されていません。特別なユニークなインデックスは、NULL値を許可していません。
図6に示すように、インデックスと主キー索引（しばしばテスト）との間の唯一の違いは？
一意のインデックス複数の表が1つのプライマリキーインデックスを持つことができ、一意のインデックスが複数存在してもよいです
主キーのインデックスが特別なユニークなインデックスです：主キー索引は、一意のインデックスである必要があり、唯一のインデックスは、主キーインデックスではありません
追加の主キーのインデックス機能：主キー、外部キーは、データの矛盾を防止し、参照整合性制約を設定することができます
7、インデックス型（高度）？
複合インデックス：複数の列は、インデックスを作成するために一緒になって、あなたは複数の列をカバーすることができます
（めったに使われない）外部キーインデックス：のみテーブルタイプInnoDBは、外部キーインデックスは、データの一貫性、整合性、およびカスケード動作を保証するために使用することができます
フルテキストインデックスは、（めったに使われない）：MySQLはフルテキストインデックスが付属していMyISAMのみに使用することができ、英語のみのフルテキスト検索で行うことができます
8、MySQLのインデックスは原則を創設しますか？
1.最適なインデックス列がWHERE句で表示されますが、列である、またはその代わりにSELECTキーワードの後の列に表示されるの句の列に参加します
2.文字列のインデックスは、プレフィックス長を開発する必要があり、あなたは宇宙指数を大幅に節約することができ
3.あまりにも多くのインデックスを作成しないようにするには、インデックスは、余分なディスクスペースを取ると、書き込み動作の効率が低下します
4.効果的にクエリの効率を改善するために、ディスク・フットプリント指標を減らすことができ、可能な限り短い主キーのデータ型を選択します
WHERE句はカラムである、またはその代わりにSELECTキーワードの後の列に現れるの句の列に参加1に最も適したインデックス列が表示され
2より大きいベースのインデックス列良好、インデックスの効果
3。文字列のインデックスは、プレフィックス長を開発する必要があり、あなたは宇宙指標の多く節約することができ
、複合インデックスは、クエリの効率を向上させることができます4.状況に基づいて、複合インデックスを作成し
、あまりにも多くのインデックスを作成5.回避し、インデックスは、書き込み動作を減らし、追加のディスク領域を占有します効率
6.できるだけ短い主キーデータ・タイプを選択し、効果的にクエリ効率を改善するために、ディスク・フットプリント指標を低減することができます
9、MySQLのインデックスの注意事項？
「％王％」インデックスのような名前が失敗します。1.likeクエリ％はフロント、あなたは、フルテキストインデックスを使用することができますすることはできません
2.前の状態または列がないの背後にある、インデックス化した場合、インデックスは使用されません
列タイプ3.が文字列では、値の引用符にクエリを与えなければならない、またはインデックスの失敗：名= 100;名前は文字列なので、引用符に100
1.複合インデックス接頭辞は、の原則に従う
名前「％王％のように：フロント、フルテキストインデックスを使用することができますすることはできません2.likeクエリ％を 」 失敗するインデックスを
3.columnがインデックスを使用することができますnullである
MySQLはフルよりもインデックスを用いて推定した場合4. ID> 1とid <表スキャンが遅くなり、インデックスを使用しないことを決定 ：100 の複数のステップとしてインデックス照会
カラムの前またはインデックスの条件が、後者はない、指標を使用しない場合5.
;名前が文字列なので、引用符で囲まれた100名= 100：6列の型が文字列である、あなたは、値にインデックスまたは失敗を引用し、クエリを与える必要があります
要約では第二に、コンテンツ
ます。https：//www.cnblogs.com/Renyi-Fan/p/11073647.htmlで再現