> つまり、ある値について検索する場合、その値を含む行が多ければ多いほど
> インデックスの効果は薄れるということかもしれません。
>
> # そういえば DBMS のインデックスはそういうもんだという話をどっかで
> # 読んだような気もする…。

 昔の話で恐縮ですが、ヒット率(条件にマッチするレコード数／全レコード数)がある程度
(15%など)を超えた場合、インデックスを読んで、実データを読んで
と、インデックスを読む行為そのものがオーバヘッドとなってしまい、データ
領域だけをすんなり読む方が早いというのがあります。たしかORACLEでは、SQL
実行中に、設定したヒット率に達したらインデックスを使わなくなるというの
があったような...。
 あとは、MySQLでLOW-DEVICEを使っていない(まだサポートしていないですよね？)
ので、UNIXファイルシステム(LinuxではEXT2)のフラグメンテーションもアクセス
スピード低下の要因になりますね。たぶん、データ領域はフォーマットされたの
だと思いますが。(ユティリティで無効領域をつぶせますが、EXT2のフラグメン
テーションまでは解消しませんよね？)
 今のところCPUパワーはくっていないようですので、データ専用のディスク(フ
ォーマット済)に出して評価できないでしょうか。
 同様の理由でインデックス領域とデータ領域は、別々のディスクにとれれば
尚、良いのですが、MySQLでできるのかは知りません。
 いずれも、10年以上も前のRDBMS構築ノウハウなので、今でも通用するかどうか
....？
 年寄でした(笑)