インデックス作成については、必ず時間をかけて読む必要があります。インデックス作成についてはたくさん書かれています。何が起こっているのかを理解することが重要です。
大まかに言えば、インデックスはテーブルの行に順序を課します。
簡単にするために、テーブルが単なる大きなCSVファイルであると想像してください。行が挿入されるたびに、最後に挿入されます。 。したがって、テーブルの「自然な」順序は、行が挿入された順序にすぎません。
そのCSVファイルが非常に初歩的なスプレッドシートアプリケーションにロードされていると想像してみてください。このスプレッドシートは、データを表示し、行に順番に番号を付けるだけです。
ここで、3番目の列で値「M」を持つすべての行を見つける必要があると想像してください。利用できるものを考えると、選択肢は1つだけです。テーブルをスキャンして、各行の3番目の列の値を確認します。行数が多い場合、この方法（「テーブルスキャン」）には長い時間がかかる可能性があります！
ここで、このテーブルに加えて、インデックスがあると想像してください。この特定のインデックスは、3番目の列の値のインデックスです。インデックスは、3番目の列のすべての値を意味のある順序（たとえばアルファベット順）で一覧表示し、それぞれについて、その値が表示される行番号の一覧を提供します。
これで、3番目の列の値が「M」であるすべての行を見つけるための優れた戦略が得られました。たとえば、バイナリ検索 を実行できます。 ！テーブルスキャンではN行（Nは行数）を調べる必要がありますが、バイナリ検索では、最悪の場合、log-nインデックスエントリのみを調べる必要があります。うわー、それは確かにはるかに簡単です！
もちろん、このインデックスがあり、テーブルに行を追加する場合（最後に、これが概念テーブルの動作方法であるため）、毎回インデックスを更新する必要があります。したがって、新しい行を作成している間はもう少し作業を行いますが、何かを検索するときに時間を大幅に節約できます。
したがって、一般に、インデックス作成は読み取り効率と書き込み効率の間にトレードオフを生み出します。インデックスがない場合、挿入は非常に高速になります。データベースエンジンは、テーブルに行を追加するだけです。インデックスを追加すると、エンジンは挿入の実行中に各インデックスを更新する必要があります。
一方、読み取りははるかに高速になります。
うまくいけば、それはあなたの最初の2つの質問をカバーします（他の人が答えたように-あなたは正しいバランスを見つける必要があります）。
3番目のシナリオはもう少し複雑です。 LIKEを使用している場合、インデックスエンジンは通常、最初の「％」までの読み取り速度に役立ちます。つまり、WHERE column LIKE'foo％bar％'を選択している場合、データベースはインデックスを使用して、columnが "foo"で始まるすべての行を検索し、その中間行セットをスキャンしてサブセットを検索する必要があります。 「バー」が含まれています。 SELECT ... WHERE column LIKE'％bar％'はインデックスを使用できません。理由がわかるといいのですが。
最後に、複数の列のインデックスについて考え始める必要があります。概念は同じで、LIKEのものと同様に動作します。基本的に、（a、b、c）にインデックスがある場合、エンジンは可能な限り左から右にインデックスを使用し続けます。したがって、列aでの検索では、（a、b）での検索と同様に、（a、b、c）インデックスを使用できます。ただし、WHERE b =5 AND c =1）
を検索している場合、エンジンは全表スキャンを実行する必要があります。これが少し光を当てるのに役立つことを願っていますが、これらのことを詳細に説明する良い記事を探すために数時間を費やすのが最善であることを繰り返し述べなければなりません。特定のデータベースサーバーのドキュメントを読むこともお勧めします。クエリプランナーがインデックスを実装して使用する方法は、かなり大きく異なる可能性があります。