1つの単一テーブルインデックス
問題が見つかりました：クエリtypeはALL、全テーブルスキャンの問題があり、インデックスが使用されておらず、Using filesort最適化が必要なファイル内に並べ替えの問題があります。
最適化を開始：
1.複合インデックスを作成する
ALERT TABLE ' article' ADD INDEX index_article_ccv ('category_id','comments','views')
或者
create index index_article_ccv on article('category_id','comments','views')
分析：複合インデックスの実際の使用は、typeあるrangeが、依然として存在しているUsing filesort紙のスケジューリングは、。comments>1これが範囲です。範囲インデックスが無効化につながる後は、後で詳細に処理されます。
これは、現在作成されているインデックスが適切ではないことを示してcomments>1います。これは、範囲クエリがあり、ファイル内で並べ替えが発生するためです。
特定の実行分析：
- タイプが範囲であることは許容されますが、それはextraに存在し
Using filesort、ファイル内の並べ替えの問題は許容できませんが、作成したインデックスが役に立たないのはなぜですか？ - 私たちはBtreeの動作原理に従っているので、最初にソート
category_idし、同じcategory_idものcommentsが発生した場合commentsはソートし、次に同じ場合はビューをソートします。 commentsフィールドがジョイントインデックスの中央にある場合、comments>1条件は範囲値であるため、mysqlはインデックスを使用して後続のビュー部分を取得できません。つまり、範囲タイプのクエリフィールドの背後にあるインデックスは無効です。
解決する
コメントインデックスをバイパスしてインデックスを再作成し、以前に作成したインデックスを削除し、新しいインデックスを作成します。
create index index_article_ccv on article('category_id','views')
2、2テーブル
1.左接続
インデックスが使用されていない場合の全表スキャン
最適化を開始：
- 右のテーブルにインデックスを追加する
左のテーブルはインデックスの取得、右のテーブルは全表スキャンです - 右のテーブルインデックスを削除し、左のテーブルインデックスを追加する
分析後
明らかに、左側は右側のテーブルを結合してインデックス効果を追加する方が良いです（ref> index）。これは、左の接続の特性によってLEF JOIN決定される条件が、右のテーブルから行を検索する方法を決定するために使用されるためです。したがって、左の接続と右のテーブル。
2.正しい接続
RIGHT JOIN条件は左側のテーブルから行を検索する方法を決定するために使用されるため、右側に両方が必要であり、左側がキーポイントである必要があります。
要約：
左結合、インデックスは右テーブルを構築し、右結合インデックスと左テーブルを構築します。
3、3テーブル接続
1. 3つのテーブルの左接続
全表スキャン
- 索引
- 実行結果
最後の2つtypeは両方refで、行の最適化は非常に良好で、効果は良好です。したがって、インデックスは、頻繁に照会する必要があるフィールドに設定するのが最適です。
要約：
- 結合ステートメントのNestedLoopサイクルの数をできるだけ減らします。「常に小さな結果セットが大きな結果セットを駆動する」-小さなテーブルが大きなテーブルを駆動する
- NestedLoop（ネストループ）の内部ループを最適化する
- 結合ステートメントのドリブンテーブルの結合条件フィールドにインデックスが作成されていることを確認してください
- ドリブンテーブルの結合条件フィールドのインデックス付けが保証されておらず、メモリリソースが十分である場合は、joinbufferの設定をスキップしないでください。
