Собственно, сабж.
Добавить вычисляемый столбец reverse([field]), построить по нему индекс и искать по нему [reverse_field] like reverse(@param) + '%' ?
Или есть еще варианты?
MSSQLSERVER2019.

Дорого :-(. В таблице более 200 млн. записей.
Может, есть вариант сопоставить "хвосту" 1-2 байтовый хэш, и соответственно, искать внутри хэша?

Дык если по нему построить индекс, он и станет PERSISTED. По крайней мере рассчитанные значения сохранятся в индексе.

Да нет, совсем наоборот! Шаблон поиска как раз произвольный.
Поле varchar(1000), заполнено некими номерами, причем 3..9 хвостовых символов имеют содержательное значение (там всякие отделы/годы закодированы).
Поле, в среднем, заполнено на 10%. В таблице 0,5 млрд. записей (когда я говорил про 200, точнее, про 180 млн., это, оказывается, только активные записи были. Там еще, оказывается, погашеные есть, их в 2 раза больше, они в соседней таблице, искать надо везде).
Номера неуникальны, но слабоповторяемы, процент дублей по номеру примерно 15%., причем максимальное количество дублей около 100, т.е. в основном номеров или 1, или, иногда 2, или крайне редко - десяток. Максимум повторов, как я сказал, в районе 100 входов. Причем есть определенная уверенность, что такое поведение - сохранится.
Цель - быстро искать по шаблону %3..9 символов длиной.
Причем это только один из вариантов поиска, еще ищут по полному совпадению и по началу n-символов%, так что индекс по номеру - есть, некластерный.
Иметь такой же, по отреверсированному полю - получается затратно, думаю, да и бессмысленно.
Думаю, сопоставить последним 9 символам какой то двубайтовый хэш, и построить индекс по нему.
Тем более, что число различных 9-ти символьных комбинаций с хвоста - всего то около 150 тысяч.

Вопрос, как такой хэш построить?
Думаю CRC16 должен хорошо подойти.
Никто не знает, как поизящнее посчитать, а лучше одной строкой?
Ну, или что-нибудь типа того...

Ну и искать, соответственно как:
Where KEY_CRC16 = CRC16(@key) and key like '%' + @key

Черт, я знал, что где то дырка.
:-)
А по трем символам строить бессмысленно, там есть комбинации, которым соответствует миллионов 20 входов.

Да понял уже :-(
Скорее всего, действительно отрежу с хвоста 8 символов, отреверсирую и сохраню как char в бинарном коллейте. И "хрен с ним, пусть тоскует"

Хотя, чисто теоретически, если подобрать такую функцию, которая монотонно росла бы от количества символов и от позиции - можно было бы по интервалу искать.
Ну т.е. если бы хеш(1) <= хеш(1яяяяяяяяя) <хеш(2) <= хеш(2я) и т.д.