なぜOracleSQLでは、条件が大きく異なる同じ列に対して2つの異なる値を使用してクエリを実行するのにかかる時間が

インデックスがないと、email_id両方のクエリに同じ時間がかかり、employeesテーブルで全表スキャンを実行するのにかかる時間が予想されます。では、なぜ1つのクエリが他のクエリよりもはるかに速く返されるのでしょうか。

仮定：

1. クエリは、変数をバインドするのではなく、実際にはハードコードされた値を使用します（つまり、使用しません select * from employee where email_id = ':1'）。
2. よりパフォーマンスの高いクエリは、実際にはadmin電子メールアドレスの検索です。

リテラルを含むクエリは通常悪いことです。各バージョンはハード解析する必要があり、カーソルキャッシュのスペースを占有します。ただし、実行パス（個別に解析されるため）やパフォーマンスプロファイルが異なる場合もあります。それがここに当てはまるようです。インデックスがない場合、アクセスパスは同じになりますが、キャッシュが原因で合計経過時間が異なる場合があります。

使用されている可能性のあるキャッシュは2つあります。

1. 偶発的なキャッシュ。のemployeeレコードを含むブロック[email protected]はすでにDBバッファキャッシュにあるため、クエリはテーブル全体を読み取る必要はありません。
2. 意図的なキャッシュ。結果セットのキャッシュを使用する電子メールアドレスで従業員にクエリを実行するものがあり、のemployeeレコード[email protected]はそこにキャッシュされます。

したがって、[email protected]キャッシュできる理由は2つあります。明らかに、同じことがどの従業員にも当てはまります。しかし、人々は[email protected]より頻繁に探しているようです[email protected]。非常に簡単に言えば、（アプリケーションやデータを知らなくても）管理者ユーザーは頻繁にクエリを実行されるため、他のランダムユーザーよりもキャッシュ内にいる可能性が高くなります。

「サーバーにQuery2をキャッシュさせるにはどうすればよいですか？」

adminユーザーが誤ってキャッシュされた場合（クエリが頻繁に行われるため、バッファ内で保温されているだけです）、できることはほとんどありません。テーブルをメモリに固定できるのは事実ですが、それは通常は悪い考えです。ほとんどの場合、データベースは私たちよりもリソースの管理に優れています。ブロックが DB バッファ キャッシュに保持されていない場合、それはあまり頻繁に使用されていないためです (DBC のサイズが正しく設定されている場合)。

アプリケーションが結果セットキャッシュを使用している場合は、のレコードを明示的に取得できます[email protected]。ただし、以前と同じ理由で、すべてのユーザーに対してこれを行うことはできません。レコードが頻繁に使用される場合は、レコードをメモリに固定したくないということです。

それは私たちを目標に導きます。ここで何を最適化しようとしていますか？ユーザーのサブセットのアクセス時間/または任意のユーザーのアクセス時間？後者の場合は、のインデックスが必要email_idです。