Оптимизация поиска в зашифрованном столбце

Question

У меня есть таблица с именем tblClient с зашифрованным столбцом с именем SSN.

В соответствии с политикой компании мы зашифровали SSN с использованием симметричного ключа (выбираемого вместо асимметричного ключа по соображениям производительности) с помощью пароля.

Вот частичный LIKE поиск по SSN объявить @SSN varchar (11) set @SSN = '111-22 -%'

open symmetric key SSN_KEY decrypt by password = 'secret'

    select  Client_ID
    from    tblClient (nolock)
    where   convert(nvarchar(11), DECRYPTBYKEY(SSN)) like @SSN

close symmetric key SSN_KEY

До шифрования поиск по 150 000 записей занимал менее 1 секунды.
но со смесью дешифрования тот же поиск занимает около 5 секунд.

Какую стратегию можно применить для оптимизации поиска по зашифрованному столбцу?

Answer 1

Одна из проблем, которую будет трудно решить, заключается в том, что для поиска с использованием подстановочных знаков требуется какой-либо просмотр индекса или таблицы, который требует дешифрования каждой строки.

Вместо этого оптимизируйте, предварительно зашифровав поисковые значения, чтобы разрешить индексирование зашифрованных значений.

Если вам потребовалось явное сопоставление, вы могли бы сделать что-то подобное, обратите внимание, что шифрование выполняется для входного значения, а не для столбца:

select  Client_ID 
from    tblClient (nolock) 
where   SSN = convert(nvarchar(11), ENCRYPTBYKEY(@SSN)) 

Однако ... для поиска вы можете захотеть изучить оптимизацию, которая вроде бы достигает этого, помещая сегменты SSN в отдельные проиндексированные поля, затем анализируя входную строку и выполняя

select  Client_ID 
from    tblClient (nolock) 
where   SSNFIRST3 = convert(nvarchar(3), ENCRYPTBYKEY( <parsed prefix here> )) 
and SSNSECOND2 = convert(nvarchar(2), ENCRYPTBYKEY( <parsed middle section here> )) 

Вы выполняете шифрование / дешифрование только для входных значений, а не строк.

Предполагается, что вы пишете немного простого кода регулярного выражения, чтобы разобрать строку поиска на отдельные части для подачи вышеуказанного запроса. Следствием вышесказанного является, по крайней мере, использование поисков по индексу, которое должно быть значительно быстрее, чем у вас сейчас, из-за ограниченного числа посещенных строк.

РЕДАКТИРОВАТЬ: я имел в виду ENCRYPTBYKEY, изменено выше.

Answer 2

Простое решение - добавить незашифрованный столбец для первых символов SSN.И это тяжелый .

Answer 3

Я предполагаю, что, зашифровав столбец, вы заставляете полное сканирование таблицы каждый раз, когда запрашиваете его (хотя, конечно, проверьте план). Создание индекса по SSN сделает шифрование бессмысленным.