最も論理的と思われるものにインデックスを付けます（たとえば、CUSTOMERSテーブルの顧客ID列など、明らかになるはずです）。
次に、アプリケーションを実行し、統計を定期的に収集して、データベースのパフォーマンスを確認します。 DB2のRUNSTATSはその一例です。MySQLにも同様のツールがあるといいのですが。
全表スキャンを実行している（または他の理由で時間がかかりすぎる）頻繁に実行されるクエリを見つけた場合は、そしてそのときのみ 、さらにインデックスを追加する必要があります。月に1回、深夜に実行されるクエリを最適化して、12：07ではなく12:05に終了できるようにすることはほとんど役に立ちません。ただし、顧客向けのクエリを5秒から2秒に短縮することは大幅な改善です（それでも遅すぎるため、顧客向けのクエリは可能であれば1秒未満にする必要があります）。
インデックスが多いほど、挿入が遅くなり、クエリが速くなる傾向があります。したがって、それは常にバランスをとる行為です。そのため、問題への特定の応答でのみインデックスを追加します。それ以外は時期尚早の最適化であり、避ける必要があります。
さらに、すでに定期的に持っているインデックスを再確認して、それらがまだ必要かどうかを確認します。これらのインデックスを追加する原因となったクエリは、それを保証するのに十分な頻度で実行されなくなった可能性があります。
正直なところ、テーブルの3つの列にインデックスを付けることで、非常に多くの行を格納する予定がない限り、問題が発生することはないと思います:-)-インデックス付けは非常に効率的です。
編集後、次のように記載されています：
私の回答では、1日あたり200レコードはデータベースにとって非常に小さな値であり、これら3つのインデックスについて心配する必要はありません。
ちょうど今週、私は1日分のトランザクションを、稼働中のデータベーステーブルの1つにインポートしました。これには、210万件のレコードが含まれていました（25台の別々のマシンから1日を通して少なくとも1秒に1つのトランザクションを取得します）。また、4つの個別の複合キーがあり、3つの個別のキーよりもいくらか集中的です。
確かに、それはDB2データベース上にありますが、IBMがそうであるとは想像できません。 MySQLがDB2負荷の0.01％未満しか処理できないというMySQLの人々よりもはるかに優れています。