Индекс SQL Server - Какое-либо улучшение для ПОДОБНЫХ запросов?

Потенциально вы можете увидеть улучшения производительности Если добавить индекс (ы), то многое зависит от специфики:)

Сколько общего размера строки составляют ваши предикатные столбцы? Сколько строк вы ожидаете совпадать? Нужно ли возвращать все строки, которые соответствуют предикату, или только верхние 1 или верхние n строк?

Если вы ищете значения с высокой избирательностью / уникальностью (так мало возвращаемых строк), а предикатные столбцы маловаты часть размера строки, индекс может быть весьма полезным. Это все равно будет сканирование, но ваш индекс будет соответствовать большему количеству строк на страницу, чем исходная таблица.

Вот пример, где общий размер строки намного больше, чем размер столбца для поиска:

create table t1 (v1 varchar(100), b1 varbinary(8000))
go
--add 10k rows of filler
insert t1 values ('abc123def', cast(replicate('a', 8000) as varbinary(8000)))
go 10000
--add 1 row to find
insert t1 values ('abc456def', cast(replicate('a', 8000) as varbinary(8000)))
go

set statistics io on 
go
select * from t1 where v1 like '%456%'
--shows 10001 logical reads

--create index that only contains the column(s) to search across
create index t1i1 on t1(v1)
go
select * from t1 where v1 like '%456%'
--or can force to 
--shows 37 logical reads

Если вы посмотрите на фактический план выполнения, то увидите, что механизм сканировал индекс и выполнил поиск закладок в соответствующей строке. Или вы можете напрямую сказать оптимизатору использовать индекс, если он не решил использовать этот план самостоятельно: выберите * из t1 с помощью (index (t1i1)), где v1 похож на «% 456%»

Если у вас есть группа столбцов для поиска только в нескольких высокоселективных, вы можете создать несколько индексов и использовать подход сокращения , Например, сначала определите набор идентификаторов (или каким бы ни был ваш PK) из вашего высокоселективного индекса, а затем выполните поиск по менее избирательным столбцам с помощью фильтра по этому небольшому набору PK.

Если вам всегда нужно возвращать большой набор строк вам почти наверняка будет лучше с помощью сканирования таблицы.

Таким образом, возможная оптимизация во многом зависит от специфики определения вашей таблицы и избирательности ваших данных.

HTH! -Adrian

Единственный другой способ (кроме использования полнотекстовой индексации), который вы могли бы повысить производительность, - это использовать "LIKE ABC%" - не добавлять подстановочные знаки на обоих концах поискового запроса - в этом случае индекс может сработать.

Если ваши требования таковы, что вам нужно иметь подстановочные знаки в обоих концах поискового запроса, вам не повезло ...

Марк

Подобно "% ABC%", всегда выполняется полное сканирование таблицы. Обойти это невозможно.

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

В качестве альтернативы в некоторых случаях может быть целесообразным денормализовать данные и предварительно обработать целевые поля в соответствующие токены, а затем добавить эти возможные условия поиска в отдельной поисковой таблице. Например, если мои данные всегда состояли из поля, содержащего шаблон «AAA / BBB / CCC», и мои пользователи искали на BBB, то я бы пометил это при вставке / обновлении (и удалении при удалении). Это также может быть одним из тех случаев, когда использование триггеров, а не кода приложения, будет гораздо предпочтительнее .

Я должен подчеркнуть, что это не совсем оптимальный метод, и его следует использовать только в том случае, если данные хорошо соответствуют подходу и по какой-то причине вы не хотите использовать полнотекстовый поиск (и производительность базы данных и т. П. сканирование действительно недопустимо). Это также может вызвать головную боль при техническом обслуживании в дальнейшем.

создать статистику по этому столбцу. sql srever 2005 оптимизировал поиск в строке, так что вы можете извлечь из этого пользу.