説明したように、できません。あなたが与えた答えは、それを最適化する必要がない場合にそれを達成する方法です。
完全にせずに最適化する必要がある場合 暗号化された値を危険にさらし、フィルターによって返され処理されるデータの量を見つけるためにプロファイルを作成したことが遅延の主な原因である場合、次のことができます。
ハッシュのサブセットを格納する新しいフィールドをテーブルに追加します。一意の電子メールアドレスの数に応じて、このサブセットの大きさを調整できます。注：このアプローチを使用して暗号化された値に関する情報をリークするため、小さいほど良いです。たとえば、メールアドレスの1バイトのハッシュを保存すると、暗号化のエントロピーが最大8ビット減少します。
クエリを実行するときは、最初にメールハッシュのサブセットを作成し、whereを配置します それらの行のみを返す句。
これはすべて、ハッシュ関数が復号化ステップよりも安価であることを前提としています。このアプローチでは、サイズを増やしたい場合はすべてのハッシュサブセットを再計算する必要があるため、パフォーマンスを大幅に向上させ、暗号化を過度に損なうことなく、成長に合わせて変更する必要がないサイズを選択することが重要です。 。
注：この状況では、MD5のようなストレートハッシュを使用しないでください。衝突の影響を受けやすいためではなく、キースペースが非常に小さくなるためです。パフォーマンスが重要で、大量のデータを保存している場合は、DOS攻撃を開始します。これにより、攻撃者は、すべてが同じサブセットにハッシュされる大量の電子メールアドレスを作成します。この問題を解決するには、HMAC を使用します。 秘密鍵で機能します。
複雑さを追加する必要がある本当のパフォーマンス上の理由がない限り、覚えておいてください-しないでください