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

对于这个例子，我们理所当然地认为varcharcol不包含“并且在这一列上没有空单元格

select * from some_table where varcharCol = ''
select * from some_table where varcharCol like ''

第一个结果是0行输出，而第二个显示整个列表。=是严格匹配的情况下，而like的作用像一个过滤器。如果过滤器没有条件，则每个数据都是有效的。

Like -由于其目的，它的工作速度稍慢，用于varchar和类似的数据。

这是我对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快得多。

在有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条记录

使用=可以避免在运行时构建查询时字符串中的通配符和特殊字符冲突。

这使程序员的工作更轻松，因为不必转义所有可能滑入LIKE子句并不能产生预期结果的特殊通配符。毕竟，=是99%的用例场景，每次都必须逃避它们将是一种痛苦。

在90年代翻白眼

我也怀疑它有点慢，但如果模式中没有通配符，我怀疑它的意义。