大塚です。

インデックスの非常に多いテーブルを作っています。
あるイベントの履歴テーブルなのですが、イベントの発生毎に
関連のあるいくつかの値を全て計算して、同じ列に挿入して
います。
それぞれで検索される可能性があり全てにインデックスをつけ
ているので、1テーブルのインデックスが10近くになっている
のですが、1テーブルあたりのインデックスは少ない方がよい
という話なので、分割すべきかどうかで迷っております。

各計算値毎に別テーブルにしようかと思ったのですが、前提
条件が

・データは挿入のみで、どの値も更新は発生しない
・特定の値だけ挿入される事はなく、イベントが発生すれば
　必ず全ての値が挿入される

という元でよく考えると、

・インデックスが10のテーブルが1つあるか、インデックスが
　1のテーブルが10個あるかの違いだけで、インデックス自体
　の数も、更新頻度も同じ。むしろそれぞれに主キーがある分
　も考慮すればインデックス数は多くなる?
・それに対し、検索の方は、テーブルが別れている分、同じ
　履歴の別の計算値を取得しようとするとSQLを複数回発生する
　なり、JOINするなりで対処する必要が生じるので、全データ
　を1テーブルに突っ込んで1クエリで全値が取得できる方が
　効率がよさそう

と思えるので、本当に1テーブルあたりのインデックス数を
減らすのが絶対に正しい事なのかどうかよく判らないのです。

1テーブルあたりに対するインデックス数を増やす事は、単に
インデックスのデータベース内での総数や更新頻度の問題だけ
でなく、別のファクターもあって避けるべき問題なのでしょう
か。
要するに、1テーブルあたりのインデックス数増加に対する
データ挿入時の処理コストの増加が、線形か非線形かを伺い
たいのですが…。

だいたい、現状で65万行、その後1年程度で320万行程度に行数
が増えそうな履歴テーブルを、できれば後数年は安定稼動させる
ための構造、として考えています。

以上、よろしくお願いいたします。