当使用SQL时,在WHERE子句中使用=而不是LIKE有任何好处吗?

没有任何特殊的运算符,LIKE和=是一样的,对吧?


当前回答

要解决最初关于性能的问题,可以归结为索引利用率。当进行简单的表扫描时,“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"时,在查询计划的创建中也可能存在可以忽略不计的差异。

其他回答

这是我对SQL 'like' vs '='性能问题的另一个答案的复制/粘贴:

一个使用mysql 5.5的个人例子:我在2个表之间有一个内部连接,一个是300万行,一个是1万行。

在索引上使用like时(没有通配符),大约需要30秒:

where login like '12345678'

使用'explain'我得到:

当对同一个查询使用'='时,大约需要0.1秒:

where login ='12345678'

使用“explain”我得到:

如您所见,类似的操作完全取消了索引seek,因此查询花费了300多倍的时间。

除了LIKE可以使用通配符外,还有一个区别在于尾随空格:=运算符忽略尾随空格,而LIKE则不会。

取决于数据库系统。

通常没有特殊字符,是的,=和LIKE是一样的。

但是,某些数据库系统可能会对不同的操作符使用不同的排序设置。

例如,在MySQL中,字符串上的=默认情况下总是不区分大小写的,所以没有特殊字符的LIKE是一样的。在其他一些RDBMS上,LIKE是不区分大小写的,而=则不是。

equals(=)操作符是一个“比较操作符,比较两个值是否相等”。换句话说,在SQL语句中,除非等式两边相等,否则它不会返回true。例如:

SELECT * FROM Store WHERE Quantity = 200;

LIKE操作符“实现了模式匹配比较”,尝试将“字符串值与包含通配符的模式字符串”进行匹配。例如:

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

LIKE通常只用于字符串,等号(我相信)更快。等号运算符将通配符视为文字字符。返回结果的差异如下:

SELECT * FROM Employees WHERE Name = 'Chris';

And

SELECT * FROM Employees WHERE Name LIKE 'Chris';

将返回相同的结果,尽管使用LIKE通常会花费更长的时间,因为它是一个模式匹配。然而,

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

And

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

将返回不同的结果,其中使用“=”只会返回带有“Chris%”的结果,LIKE操作符将返回以“Chris”开头的任何结果。

一些好的信息可以在这里找到。

=比LIKE快得多。

在有11GB数据和超过1000万条记录的MySQL上测试,f_time列被索引了。

SELECT * FROM XXXXX WHERE f_time = '1621442261' -花费0.00s并返回330条记录

SELECT * FROM XXXXX WHERE f_time like '1621442261' -花费44.71秒并返回330条记录