メッセージ付きのテーブルがあります。したがって、列、、、などがあります。id特定のユーザーの受信トレイを表示する場合は、select ステートメントを記述します。fromto
where to = 'username' order by id desc limit 0,20;
これにより、そのユーザーの最初の 20 件のメッセージが表示されます。ですから明らかにto列にインデックスを付けるべきで、主キーなのでid列にはすでにインデックスがありますが、（to、id）にインデックスを一緒に設定した方がよいでしょうか？
残念ながら、答えはSOに適したものよりも大きくなっています。人々はこれについて本を書いています。
単純なレベルでは、インデックスをオンに(to, id DESC)することが、そのクエリを解決するのに最適です。インデックスの最初のフィールドにより、データの検索が容易になり、対象のすべてのレコードが 1 つの連続したブロックに含まれるようになります。インデックスの 2 番目のフィールドは、連続するブロックが事前に並べ替えられることを保証し、最初の 20 レコードを簡単に見つけることができるようにします。
しかし、その指標を維持することも問題です。このようなインデックスは、断片化が非常に発生しやすい可能性があります。夜間のメンテナンス ジョブでインデックスを再構築する容量はありますか? また、インデックスが多いほど、ディスク領域のオーバーヘッドが大きくなります。必要になる可能性のあるクエリごとに新しいインデックスを作成するためのディスク容量はありますか? また、インデックスを追加すると、書き込みオーバーヘッドが増加します。テーブルが書き込まれる頻度と、待ち時間を最小限に抑えることの重要性は? フィルタリング/検索/結合しているフィールドに加えて、クエリするフィールドを追加することは、インデックスを読み取るだけでよく、ベース テーブルに「結合」する必要がないことも意味します。その利点は、より多くの広範なインデックスを持つことによるオーバーヘッドのさらなる増加に見合う価値があるでしょうか?
これは非常に広い範囲の回答を持つ良い質問ですが、ここではその表面をくすぐっただけです。