email_idの索引を使用しないと、両方の問合せが同じ時間（employees表で全表スキャンを実行するのにかかる時間）がかかることが予想されます。だから、なぜ1つのクエリーが他のクエリーよりもずっと速く戻るでしょうか？
仮定：
- あなたのクエリが本当に変数（すなわちない
select * from employee where email_id = ':1'）と結合するというし、ハードコードされた値を使用します。
- more performativeクエリは実際に
admin電子メールアドレスを検索しています。
リテラルを含むクエリは、通常、悪いことです。それぞれのバージョンをハード解析する必要があり、カーソルキャッシュ内の領域を占有します。ただし、別々の実行パス（別々に解析されるため）またはパフォーマンスプロファイルを持つこともできます。それはここにあるようです。索引がなければ、アクセス・パスは同じになりますが、キャッシングによって合計経過時間が異なる可能性があります。
再生可能なキャッシュは2つあります。
- 誤ったキャッシュ。
[email protected]のemployeeレコードを含むブロックはすでにDBバッファー・キャッシュに入っているので、照会は表全体を読み取る必要はありません。
- 意図的なキャッシュ。 resultset cachingを使用し、
employeeレコードを[email protected]とした電子メールアドレスで従業員に照会するものがあります。
したがって、[email protected]がキャッシュされる理由は2つあります。明らかに同じことは、どの従業員にも当てはまる可能性があります。しかし、人々はよりも頻繁に[email protected]を探しているようです。非常に単純に（アプリケーションやデータを知らずに）、管理ユーザーは頻繁に照会され、他のランダムユーザーと比べてキャッシュに入れる可能性が高くなります。
「サーバーにQuery2をキャッシュさせるにはどうすればよいですか？」それはそう頻繁に照会ますので、それは単にバッファに保温しています - - 本当に多くのあなたが行うことができないのです
adminユーザーが誤ってキャッシュされている場合。テーブルをメモリに固定することは可能ですが、それは通常は悪い考えです。たいていの場合、DBバッファーはDBバッファー・キャッシュに保持されていないと、リソースが非常に頻繁に使用されないためです（DBCが正しくサイズ設定されていると仮定して）。
アプリケーションで結果セットのキャッシュを使用している場合は、明示的にそのレコードを[email protected]に取得できます。しかし、これまでと同じ理由で、すべてのユーザーに対してこれを行うことはできません。頻繁にレコードが使用されている場合、メモリーにレコードを挿入する必要はありません。
これは私たちを目標に導きます。何をここで最適化しようとしていますか？サブセットのアクセス時間/ユーザーのアクセス時間後者の場合は、email_idのインデックスが必要です。
出典
2017-07-18 08:37:24
APC
は、多くのアプローチの長所と短所を言及するために、ありがとうございます。私がインデックスを作成していなかったのは、ユーザーのサブセットのクエリを最適化したかったからです。 – FTW