当設問の「差異1」について質問になります。

■差異1
  処理5は、どの時間帯でもバッファヒット率が90%を超え、
  応答時間は見積りの約50分の1だった。

■問
  最も可能性が高いと考えられる差異の発生原因を述べよ。

■解答
  "機器ログ"テーブルは、住居番号、年月日順に行を追加したことで、
  クラスタ率が高くなったこと

また、某解説書（一部抜粋）では
--------------------------------------------------
"機器ログ"テーブルの主キーは｛住居番号、年月日、ログ番号｝です。
本番環境ではデータが随時追加されますので、年月日順に行が追加されると考えられます。
しかし、性能テストでは、"機器ログ"テーブルのテストデータの作成要領に
「連続するログ番号を設定して、住居番号、年月日順に、1日当たり平均200行を追加する」
とあり、住居番号、年月日順に行を追加したことがわかります。
住居番号、年月日順に行を追加すると、"機器ログ"テーブルの主キーの並びと同じ順となりますので、クラスタ率が本番環境よりも高くなってしまうことが想定されます。
--------------------------------------------------
と解説がありました。


ここでちょっと自分が気になっているのが、インデックスは効かないのか？という点です。
一応、問題文中の「2．テーブル定義表の作成」の(5)で、
  > 主キー及び外部キーには、索引を定義する。
とあるので、機器ログTBLのPKである｛住居番号、年月日、ログ番号｝にインデックスが設定されていると想定しています。
そうなると結局、本番環境でデータが随時追加される際に
住居番号順、年月日順、そしてログ番号順 にデータがソートされると思うので、
結果的に差異は生まれないのでは？（見積り応答時間が誤り？）などと思ったのですが、どうなんでしょう。。

この辺りのクラスタ率やらあまり知見がある方ではないので
どなたかご教示いただけると幸いです。

> そうなると結局、本番環境でデータが随時追加される際に住居番号順、年月日順、そしてログ番号順 にデータがソートされる
  テスト環境と本番環境の索引は、住居番号順、年月日順、ログ番号順にソートされているが、実データを要確認。
  テスト環境の実データは、住居番号順、年月日順、ログ番号順に登録するので、住居番号順、年月日順、ログ番号順に集まる。一方、本番環境の実データは、年月日順、早い者順。要するに、住居番号とログ番号は、より多くのページを探索しないと集まらない。
  索引構成が同じでも、実データの集まり具合が悪い場合、索引構成と集まり具合が違う場合、より多くのページを探索することになったり、表探索することになったり。