= и LIKE не то же;

1. = соответствия точная строка
2. LIKE соответствия строка, которая может содержать подстановочные знаки (%)

Действительно это сводится к тому, что Вы хотите, чтобы запрос сделал. Если Вы подразумеваете, что точное совпадение затем использует =. Если Вы имеете в виду более нечеткое соответствие, то используйте КАК. Высказывание, что Вы имеете в виду, обычно является хорошей политикой с кодом.

ПОДОБНОЕ ключевое слово, несомненно, идет с "ценником производительности", присоединенным. Тем не менее, если у Вас будет поле ввода, которое могло бы потенциально включать подстановочные символы, которые будут использоваться в Вашем запросе, то я рекомендую использовать КАК , только если вход содержит один из подстановочных знаков. Иначе используйте стандарт, равный сравнению.

С наилучшими пожеланиями...

Используя = избегает подстановочных знаков и конфликтов специальных символов в строке, когда Вы создаете запрос во время выполнения.

Это делает жизнь программиста легче, не имея необходимость выйти из всех специальных подстановочных символов, которые могли бы закрадываться в оператор LIKE и не приведение к намеченному результату. В конце концов, = 99%-й сценарий варианта использования, это была бы боль для выхода из них каждый раз.

закатывает глаза в 90-х

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

Зависит от системы баз данных.

Обычно без специальных символов, да, = и КАК то же.

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

, Например, в сравнениях MySQL с = на строках всегда нечувствительно к регистру по умолчанию, таким образом, КАК без специальных символов то же. На некотором другом RDBMS ЛЮБЯТ, нечувствительно к регистру, в то время как = не.

Одно различие - кроме возможности использовать подстановочные знаки с ПОДОБНЫМ - находится в конечных пробелах: = оператор игнорирует конечный пробел, но КАК не делает.

LIKE и = отличаются. LIKE то, что Вы использовали бы в поисковом запросе. Это также позволяет подстановочные знаки как _ (простой символьный подстановочный знак) и % (мультисимвольный подстановочный знак).

= должен использоваться, если Вы хотите точные совпадения, и это будет быстрее.

Этот сайт объясняет LIKE

Равняние (оператор =) является "оператором сравнения, сравнивает два значения для равенства". Другими словами, в SQL-операторе, это не возвратит true, если обе стороны уравнения не будут равны. Например:

SELECT * FROM Store WHERE Quantity = 200;

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

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

КАК обычно используется только со строками и равняется (я верю), быстрее. Равняется подстановочным символам обработок оператора как буквенным символам. Различие в возвращенных результатах следующие:

SELECT * FROM Employees WHERE Name = 'Chris';

И

SELECT * FROM Employees WHERE Name LIKE 'Chris';

возвратил бы тот же результат, хотя использование КАК будет обычно занимать больше времени, поскольку это - соответствие шаблона. Однако

SELECT * FROM Employees WHERE Name = 'Chris%';

И

SELECT * FROM Employees WHERE Name LIKE 'Chris%';

возвратил бы различные результаты, куда использование "=" результаты только в результатах с "% Chris", возвращаемым и т.п. оператор, возвратит что-либо запускающееся с "Chris".

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

При поиске точного совпадения можно использовать обоих, = и КАК.

Используя "=" крошечный бит быстрее в этом случае (поиск точного совпадения) - можно проверить это сами при наличии того же запроса дважды в Studio управления SQL Server, однажды использующий "=", после того как использующий "КАК" и затем использующий "Запрос" / "Включают фактический план выполнения".

Выполняют два запроса, и необходимо видеть результаты дважды плюс два фактических плана выполнения. В моем случае они были разделены 50% по сравнению с 50%, но "=" план выполнения имеет меньшую "предполагаемую стоимость поддерева" (отображенный, когда Вы нависаете над крайним левым полем "SELECT") - но снова, это - действительно не огромная разница.

, Но когда Вы начнете искать с подстановочными знаками в Вашем КАК выражение, поисковая производительность будет неясный. Поиск "КАК % Фрезы" может все еще быть довольно быстрым - SQL Server может использовать индекс на том столбце, если существует тот. Поиск "КАК %expression %" является ужасно медленным, так как единственный способ, которым SQL Server может удовлетворить этот поиск, путем выполнения полного сканирования таблицы. Так будьте осторожны со своим LIKE's!

Marc

Чтобы ответить на исходный вопрос, касающийся производительности, он сводится к использованию индекса . Когда происходит простое сканирование таблицы, «LIKE» и «=» идентичны . Когда используются индексы, это зависит от того, как сформировано предложение LIKE. Более конкретно, каково расположение подстановочных знаков?

Примите во внимание следующее:

CREATE TABLE test(
    txt_col  varchar(10) NOT NULL
)
go

insert test (txt_col)
select CONVERT(varchar(10), row_number() over (order by (select 1))) r
  from master..spt_values a, master..spt_values b
go

CREATE INDEX IX_test_data 
    ON test (txt_col);
go 

--Turn on Show Execution Plan
set statistics io on

--A LIKE Clause with a wildcard at the beginning
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '%10000'
--Results in
--Table 'test'. Scan count 3, logical reads 15404, physical reads 2, read-ahead reads 15416, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index SCAN is 85% of Query Cost

--A LIKE Clause with a wildcard in the middle
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '1%99'
--Results in
--Table 'test'. Scan count 1, logical reads 3023, physical reads 3, read-ahead reads 3018, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost for test data, but it may result in a Table Scan depending on table size/structure

--A LIKE Clause with no wildcards
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col like '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO

--an "=" clause = does Index Seek same as above
DBCC DROPCLEANBUFFERS
SELECT txt_Col from test where txt_col = '10000'
--Results in
--Table 'test'. Scan count 1, logical reads 3, physical reads 2, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
--Index Seek is 100% of Query Cost
GO


DROP TABLE test

Также может быть незначительная разница в создании плана запроса при использовании "=" и "LIKE".