Индекс SQL Server - Любое улучшение для запросов LIKE?

У нас есть запрос, который исходит из довольно большой таблицы, которая, к сожалению, должна использовать LIKE '% ABC%' на пару полей varchar, чтобы пользователь мог искать частичные имена и т.д. SQL Server 2005

Будет ли добавление индекса в эти поля varchar помогать любому с точки зрения производительности выборочного запроса при использовании LIKE или в основном игнорировать индексы и выполнять полное сканирование в этих случаях?

Любые другие возможные способы повышения производительности при использовании LIKE?

Ответ 1

Только если вы добавляете полнотекстовый поиск в эти столбцы и используете возможности полнотекстового запроса SQL Server.

В противном случае нет, индекс не поможет.

Ответ 2

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

Сколько из общего размера строки являются вашими исходными столбцами? Сколько строк вы ожидаете? Вам нужно вернуть все строки, соответствующие предикату, или только верхние 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%'

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

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

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

НТН! -Adrian

Ответ 3

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

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

Марк

Ответ 4

Подобно '% ABC%', всегда будет выполняться полное сканирование таблицы. Об этом нет.

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

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

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

Ответ 5

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