Както е описано, не можете. Отговорът, който сте дали, е начинът, по който бихте го постигнали, ако не е необходимо да го оптимизирате.
Ако трябва да го оптимизирате без напълно компрометирането на криптираната стойност и профилирането, за да откриете количеството данни, върнати и обработени от вашия филтър, е основна причина за забавяне, можете да направите следното.
Добавете ново поле към таблицата, което ще съхранява подмножество от хеш. В зависимост от броя на уникалните имейл адреси, можете да настроите колко голямо е това подмножество. Забележка:Колкото по-малко, толкова по-добре, тъй като изтичате информация за криптираната стойност, използвайки този подход. Например, ако съхранявате 1 байтов хеш на имейл адреса, вие намалявате ентропията на криптирането с ~8 бита.
Когато правите заявка, първо създайте подмножеството на хеша на имейла и поставете where клауза за връщане само на тези редове.
Всичко това предполага, че хеш-функцията е по-евтина от стъпката за декриптиране. Този подход ще изисква от вас да преизчислите всички хеш подмножества, ако искате да увеличите размера му, така че е важно да изберете размер, който значително увеличава производителността, не компрометира ненужно криптирането и най-вероятно няма да се налага да се променя с растежа .
Забележка:В тази ситуация не трябва да използвате пряк хеш като MD5. Не поради податливостта му към сблъсъци, а защото ключовото пространство ще бъде толкова малко. Ако производителността е важна и съхранявате големи количества данни, отваряте себе си DOS атаки, при които нападателят създава големи количества имейл адреси, които всички хешират към едно и също подмножество. За да се справите повече с този проблем, използвайте HMAC функция със секретен ключ.
Запомнете, освен ако нямате истински причини за ефективността да се налага да добавяте сложност – не го правете
