テーブルには約10Kの行があります。この表の特定の列の個別の値を含む選択ドロップダウンがあるフォームが必要です。問題の列にインデックスがあります。DBインデックスの速度とキャッシング
パフォーマンスを向上させるために、個別の値を含むキャッシュテーブルを作成しました。そのため、10K行に対してselect distinct field from tableを実行する必要はありませんでした。意外なことに、select * from cachetable（10行）を実行しているように見えるのは、10K行とは異なる選択を行うよりも速くないということです。どうしてこれなの？インデックスはすべて仕事をしていますか？メインテーブルのどの行がキャッシュテーブルをクエリすることでパフォーマンスが向上するのでしょうか？
DBの場合、10K行はなしです。実際の計算時間が最小で、ほとんどが他の一定のオーバーヘッドによって消費されるため、大きな違いはありません。
違いを気付いてから予測するのは難しいですが、おそらく約100万行になるでしょう。すでにキャッシュを設定して、それはあなたが同様にそれを残すことがあり、有害ではない場合
これは、多くの要因に依存
10k行はあまりありません... 500k〜100万行に達したら気をつけてください。
インデックスは、特にそのインデックスに10種類の値がある場合には効果的です。
- 。メモリの量を、あなたのDBは、持っているの行のサイズテーブル、パラメータ化されたクエリの使用などがありますが、一般に10Kは多くの行ではなく、特にテーブルの索引付けが適切であれば、現代のRDBMSには何の汗も出ません。
一般的には、テーブル上のパフォーマンス上の問題に注意を払うだけですが、100K行のマークを渡すと500Kは通常正しく索引を付けてアクセスすると問題の原因にはなりません。パフォーマンスは通常、大規模なテーブルで壊滅的に落ちる傾向があります.500K行では問題ありませんが、600Kでクロールすることはできますが、そのような問題にぶつかる前には長い道のりがあります。
10KでのクエリはおそらくHASH SORT UNIQUEを使用します。
10Kは、ほとんどの場合、db_buffersとhash_area_sizeに収まるため、すべての操作がメモリ内で実行されるため、違いはありません。
しかし、クエリがより複雑なクエリの一部として使用される場合、または他のデータによってスワップアウトされる場合は、データにアクセスするためにdisk I/Oが必要な場合があります。
複数のセッション（ユーザーが接続する数のセッション）でループを実行し、その場合の動作を確認してください。
インデックスはすべて作業していますか？
実行計画を表示することで、クエリの実行方法を知ることができます。
たとえば、これを試してみてください。
explain plan for select distinct field from table;
select * from table(dbms_xplan.display);
私はあなたがその上BY ORDERが含まれていなかったことに気づきます。 ORDER BYを含まない場合、結果セットの順序はランダムです。特にoracleがHASHアルゴリズムを使用して別個のリストを作成している場合は特にそうです。あなたはそれをチェックすべきです。
インデックスを使用していると思われる元のクエリの実行計画とキャッシュテーブルに基づく実行計画を見てみましょう。たぶんそれらを掲示し、実際に何が起こっているのかをコメントすることができます。
キャッシュテーブルは、通常、マテリアライズドビューとして実装されます。特に、マスターテーブルが一般にかなり静的な場合は特にそうです。
真剣早すぎる最適化。データベースを仕事に任せることができます。設定に微調整を加えることができます（特に、複数のキャッシュタイプと設定を持つMySQLの場合）。
列に索引がある場合、すべての値が索引に含まれているため、dbmsは表を検索する必要がありません。それはちょうど10のエントリを持っているインデックスを見ます。これが主に読み取り専用のデータである場合は、そのデータをメモリにキャッシュします。キャッシングは、作業のデータベースを解放することによってスケーラビリティと多くを助けます。ユーザーがいないデータベースですばやく実行されるクエリは、30回のクエリが同時に実行されているとパフォーマンスが低下する可能性があります。
-1：b-treeインデックスには10個のエントリがありません。ヌル以外の行ごとに1つのエントリがあり、各エントリにはROWIDが含まれています。 –
将来の計画とスケーラビリティについては、純粋なメモリなどを使用するインデックスサービスをTCP DBラウンドトリップよりも高速に調べることが必要な場合があります。多くの人々（自分自身を含む）は、データをフラットファイルに正規化することでこれを達成するためにLuceneを使用します。
Luceneには、ファイルシステムへの依存性を取り除き、大幅に高速化するインデックスをすべてメモリに構築できるRam Drive Directoryインデクサが組み込まれています。
最近、Webサービスでラップドライブのインデックスを1つラップするシステムを構築しました。次に、高可用性と高速性のためのWebサービスへの私のAjaxのようなドロップダウン・クエリを持っています - db層なし、ファイル・システムなし、純粋なメモリ、リモートtcpパケット速度の場合。
+1実行計画を確認する – eduncan911