Производительность SQL 'like' vs '='

Этот вопрос охватывает то, что мне интересно, но ответы на него не совсем точны.

Может показаться, что в целом «=» быстрее, чем «нравится» при использовании подстановочных знаков. Похоже, это общепринятое мнение. Однако давайте предположим, что у меня есть столбец, содержащий ограниченное количество различных фиксированных, жестко запрограммированных идентификаторов varchar, и я хочу выбрать все строки, соответствующие одному из них:

select * from table where value like 'abc%'

и

select * from table where value = 'abcdefghijklmn'

'Like' должно проверять только первые три символа, чтобы найти совпадение, тогда как '=' должен сравнивать всю строку. В этом случае мне кажется, что подобное имело бы преимущество при прочих равных условиях.

Это общий академический вопрос, поэтому он не имеет значения, какая БД возникла при использовании SQL Server 2005.

См. Https://web.archive.org/web/20150209022016/http://myitforum.com/cs2/blogs/jnelson/archive/2007/11/16/108354.aspx

Цитата оттуда:

правила использования индекса с LIKE примерно такие:

• Если в ваших критериях фильтрации используется equals = и поле проиндексировано, то, скорее всего, будет использоваться INDEX / CLUSTERED INDEX SEEK.

• Если в ваших критериях фильтрации используется LIKE без подстановочных знаков (например, если у вас есть параметр в веб-отчете, который МОЖЕТ иметь%, но вместо этого вы используете полную строку), то вероятность использования индекса примерно такая же, как # 1. Повышенная стоимость почти ничего.

• Если в ваших критериях фильтрации используется LIKE, но с подстановочным знаком в начале (как в Name0 LIKE '% UTER'), гораздо меньше шансов использовать индекс, но он все равно может, по крайней мере, выполнить сканирование индекса для полного или частичного диапазона индекс.

• ОДНАКО, если в ваших критериях фильтра используется LIKE, но он начинается с STRING FIRST и имеет подстановочные знаки где-то ПОСЛЕ этого (как в Name0 LIKE 'COMP% ER'), тогда SQL может просто использовать INDEX SEEK, чтобы быстро найти строки с одинаковыми первыми начальные символы, а затем просмотрите эти строки для точного совпадения.

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

Это ощутимая разница.

Выполните следующее:

Create Table #TempTester (id int, col1 varchar(20), value varchar(20))
go

INSERT INTO #TempTester (id, col1, value)
VALUES
(1, 'this is #1', 'abcdefghij')
GO

INSERT INTO #TempTester (id, col1, value)
VALUES
(2, 'this is #2', 'foob'),
(3, 'this is #3', 'abdefghic'),
(4, 'this is #4', 'other'),
(5, 'this is #5', 'zyx'),
(6, 'this is #6', 'zyx'),
(7, 'this is #7', 'zyx'),
(8, 'this is #8', 'klm'),
(9, 'this is #9', 'klm'),
(10, 'this is #10', 'zyx')
GO 10000

CREATE CLUSTERED INDEX ixId ON #TempTester(id)CREATE CLUSTERED INDEX ixId ON #TempTester(id)

CREATE NONCLUSTERED INDEX ixTesting ON #TempTester(value)

Потом:

SET SHOWPLAN_XML ON

Потом:

SELECT * FROM #TempTester WHERE value LIKE 'abc%'

SELECT * FROM #TempTester WHERE value = 'abcdefghij'

Полученный план выполнения показывает, что стоимость первой операции LIKEсравнения примерно в 10 раз дороже, чем =сравнение.

Если вы можете использовать =сравнение, сделайте это.

Вы также должны иметь в виду, что при использовании likeнекоторые разновидности sql будут игнорировать индексы, и это снизит производительность. Это особенно верно, если вы не используете шаблон «начинается с», как в вашем примере.

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

При этом шаблон «начинается с» может быть оптимизирован в sql server. Он будет использовать индекс таблицы. EF 4.0 перешел likeна именно StartsWithпо этой причине.

Если valueнеиндексировано, оба результата приводят к сканированию таблицы. Разница в производительности в этом сценарии будет незначительной.

Если valueон проиндексирован, как указывает Даниэль в своем комментарии, =результатом будет поиск индекса, который имеет производительность O (log N). КАК будет (скорее всего - в зависимости от того, как оно селективного) в результате частичного сканирования индекса >= 'abc'и < 'abd'который потребует больше усилий , чем =.

Обратите внимание, что я говорю здесь о SQL Server - не всем СУБД понравится LIKE.

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

Итак, как сделать LIKEи =сравнить с точки зрения SARGability? LIKE, при использовании с выражением, которое не начинается с константы (например, при использовании LIKE '%something'), по определению не относится к SARGabale. Но делает ли это возможным =или LIKE 'something%'надежным? Нет. Как и на любой вопрос о производительности SQL, ответ заключается не в запросе текста, а в развернутой схеме. Эти выражения могут быть SARGable, если для них существует индекс.

Так что, по правде говоря, есть небольшие различия между =и LIKE. Но спросить, является ли тот или иной оператор «быстрее» в SQL, все равно что спросить: «Что идет быстрее, красная машина или синяя машина?». Вам следует задавать вопросы о размере двигателя и весе автомобиля, а не о цвете ... Чтобы подойти к вопросам об оптимизации реляционных таблиц, вам следует искать свои индексы и выражения в предложении WHERE (и других предложениях, но обычно это начинается с ГДЕ).

Личный пример с использованием mysql 5.5: у меня было внутреннее соединение между двумя таблицами, одной из 3 миллионов строк и одной из 10 тысяч строк.

При использовании лайка для индекса, как показано ниже (без подстановочных знаков), это заняло около 30 секунд:

where login like '12345678'

используя "объяснить", я получаю:

При использовании '=' в том же запросе потребовалось около 0,1 секунды:

where login ='600009'

Используя «объяснить», я получаю:

Как видите, likeпоиск по индексу полностью отменен, поэтому запрос занял в 300 раз больше времени.

Возможно, вы ищете полнотекстовый поиск .

В отличие от полнотекстового поиска, предикат LIKE Transact-SQL работает только с шаблонами символов. Кроме того, вы не можете использовать предикат LIKE для запроса отформатированных двоичных данных. Более того, запрос LIKE к большому количеству неструктурированных текстовых данных выполняется намного медленнее, чем эквивалентный полнотекстовый запрос к тем же данным . Запрос LIKE для миллионов строк текстовых данных может занять несколько минут; тогда как полнотекстовый запрос может занять несколько секунд или меньше для тех же данных, в зависимости от количества возвращаемых строк.

Перво-наперво,

они не всегда равны

    select 'Hello' from dual where 'Hello  ' like 'Hello';

    select 'Hello' from dual where 'Hello  ' =  'Hello';

когда вещи не всегда равны, говорить об их производительности не так актуально.

Если вы работаете со строками и только с символьными переменными, можно говорить о производительности. Но не используйте подобные и "=" как взаимозаменяемые.

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