Не повод для прыжка в середину индекса - это ведь проверка на вхождение, а не на начало. Я глянул в своей Cache for Windows (x86-32) 2008.2: планы обоих запросов абсолютно одинаковые (как и скорость выполнения). У меня поле Name проиндексировано простым (не bitmap) индексом. По любому, надо планы запросов смотреть.

AlexKB, так и я о том же :) Кстати, даже если планы обоих запросов совпали, стоит поискать несовпадающие детали в сгенерированных INT-кодах. Ясно, что в общем случае у LIKE должна быть более сложная обработка, и оптимизируется ли она до '[' в тех случаях, когда это возможно, еще вопрос. Есть подозрение, что нет :(.

krvsaТ.е. косвенное обращение + проверка по шаблонуДа, оптимизация здесь не просматривается. Но все равно, не повод это для почти стократного проигрыша в быстродействии варианту с "[" (тем более на современном процессоре).
AlexKBа вот пива мы с Вами давно уже не пили...+1
Партнеров на Украине у нас еще нет - чем не повод? :)

=Dimon=поробуйте этот запрос сделать без индексного поля в Каше 2008.2 и в Каше 5.2Да я и так Вам верю :), возможно, что-то ухудшилось в обработке неиндексированных полей в последних версиях. Но мне кажется, обсуждение переходит в чисто академическую плоскость, ибо:
- В документации LIKE и [ явно означены как отдельные операторы, и нигде не сказано, что один может сводиться к другому. Поэтому стоит ли использовать более общий (и заведомо более сложный в обработке) оператор, в тех случаях, когда вполне сгодится более простой?
- С неиндексированными полями в Cache SQL по жизни всё не слава Богу, не здесь, так в другом месте аукнется. Заметьте, что все, пытавшиеся Вам помочь, сразу (по умолчанию) решили, что поле проиндексировано.