等于（=）与LIKE

Question

使用SQL时，在=子句而不是WHERE中使用LIKE有什么好处吗？

没有任何特殊操作符，LIKE和=是相同的，对吧？

Answer 1

Answer 2

equals（=）运算符是“比较运算符比较两个值的相等性”。换句话说，在SQL语句中，除非等式的两边相等，否则它不会返回true。例如：

SELECT * FROM Store WHERE Quantity = 200;

LIKE运算符“实现模式匹配比较”，尝试将“字符串值与包含通配符的模式字符串匹配”。例如：

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

LIKE通常只用于字符串和equals（我相信）更快。 equals运算符将通配符视为文字字符。返回结果的差异如下：

SELECT * FROM Employees WHERE Name = 'Chris';

和

SELECT * FROM Employees WHERE Name LIKE 'Chris';

会返回相同的结果，但使用LIKE通常需要更长的时间作为模式匹配。然而，

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

和

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

将返回不同的结果，其中使用“=”仅导致返回“Chris％”的结果，LIKE运算符将返回以“Chris”开头的任何内容。

希望有所帮助。可以找到一些好的信息here。

Answer 3

LIKE和=不同。 LIKE是您在搜索查询中使用的内容。它还允许使用_（简单字符通配符）和%（多字符通配符）等通配符。

=如果您想要完全匹配，则应该使用它，并且会更快。

This site explains LIKE

Answer 4

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

使用mysql 5.5的个人示例：我在2个表之间有一个内连接，其中一个是300万行，另一个是1万行。

在下面的索引上使用like（没有通配符）时，花了大约30秒：

where login like '12345678'

使用＆＃39;解释＆＃39;我明白了：

使用＆＃39; =＆＃39;在同一个查询中，花了大约0.1秒：

where login ='12345678'

使用＆＃39;解释＆＃39;我明白了：

正如您所看到的，like完全取消了索引搜索，因此查询花费了300倍的时间。

Answer 5

除了可能在LIKE中使用通配符之外，其中一个区别在于尾随空格：=运算符忽略尾随空格，但LIKE不会。

Answer 6

取决于数据库系统。

一般没有特殊字符，是，=和LIKE是相同的。

但是，某些数据库系统可能会以不同的运算符对待排序规则设置。

例如，在MySQL中，与= on字符串的比较默认情况下始终不区分大小写，因此没有特殊字符的LIKE是相同的。在其他一些RDBMS上，LIKE不区分大小写，而=不是。

Answer 7

对于这个例子，我们理所当然地认为varcharcol不包含''并且没有针对该列的空单元格

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

第一个导致0行输出，而第二个导出整个列表。 =是严格匹配的情况，而像过滤器一样。如果过滤器没有标准，则每个数据都有效。

喜欢 - 由于它的目的，它的工作速度稍慢，并且打算用于varchar和类似的数据。

Answer 8

在运行时生成查询时，使用=避免字符串中的通配符和特殊字符冲突。

这使得程序员的生活变得更加容易，因为不必转义可能在LIKE子句中滑动并且不产生预期结果的所有特殊通配符。毕竟，=是99％的用例场景，每次都要逃避它们会很痛苦。

在90年代翻白眼

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

Answer 9

如果您搜索完全匹配，则可以同时使用=和LIKE。

在这种情况下使用“=”会快一点（搜索完全匹配） - 您可以通过在SQL Server Management Studio中使用相同的查询两次来检查一次，一次使用“=”，一次使用“LIKE” “，然后使用”查询“/”包括实际执行计划“。

执行两个查询，您应该看到两次结果，再加上两个实际的执行计划。在我的情况下，他们被分为50％和50％，但“=”执行计划有一个较小的“估计子树成本”（当你将鼠标悬停在最左边的“SELECT”框上时显示） - 但同样，它确实是没有太大的区别。

但是当您在LIKE表达式中使用通配符开始搜索时，搜索性能将会变暗。搜索“LIKE Mill％”仍然可以非常快 - SQL Server可以在该列上使用索引（如果有的话）。搜索“LIKE％expression％”的速度非常慢，因为SQL Server能够满足此搜索的唯一方法是进行全表扫描。所以要小心你的喜欢！

马克

Answer 10

要解决有关性能的原始问题，请归结为索引利用率。当发生简单的表扫描时，“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

使用“=”vs“LIKE”时，查询计划的创建可能会有微不足道的差异。

Answer 11

除了通配符之外，=和LIKE之间的差异将取决于SQL服务器的类型和列类型。

举个例子：

CREATE TABLE testtable (
  varchar_name VARCHAR(10),
  char_name CHAR(10),
  val INTEGER
);

INSERT INTO testtable(varchar_name, char_name, val)
    VALUES ('A', 'A', 10), ('B', 'B', 20);

SELECT 'VarChar Eq Without Space', val FROM testtable WHERE varchar_name='A'
UNION ALL
SELECT 'VarChar Eq With Space', val FROM testtable WHERE varchar_name='A '
UNION ALL
SELECT 'VarChar Like Without Space', val FROM testtable WHERE varchar_name LIKE 'A'
UNION ALL
SELECT 'VarChar Like Space', val FROM testtable WHERE varchar_name LIKE 'A '
UNION ALL
SELECT 'Char Eq Without Space', val FROM testtable WHERE char_name='A'
UNION ALL
SELECT 'Char Eq With Space', val FROM testtable WHERE char_name='A '
UNION ALL
SELECT 'Char Like Without Space', val FROM testtable WHERE char_name LIKE 'A'
UNION ALL
SELECT 'Char Like With Space', val FROM testtable WHERE char_name LIKE 'A '

• 使用MS SQL Server 2012时，比较中将忽略尾随空格，但当列类型为LIKE时，VARCHAR除外。

• 使用MySQL 5.5时，=的结尾空格将被忽略，但LIKE和CHAR的结尾空格将被VARCHAR忽略。< / p>

• 使用PostgreSQL 9.1时，使用=的{​​{1}}和LIKE空格都很重要，VARCHAR则不重要（请参阅documentation }）。

  CHAR的行为也因LIKE而异。

  使用与上述相同的数据，在列名also makes a difference上使用明确的CHAR：

  CAST

  这只返回＆＃34; CAST的行和＃34;和＆＃34; CAST col＆＃34;。

Answer 12

LIKE关键字无疑附带了“性能价格标签”。也就是说，如果您的输入字段可能包含要在查询中使用的通配符，我建议仅在输入包含其中一个通配符时使用LIKE 。否则，使用等于比较的标准。

最好的问候......

Answer 13

实际上，它归结为您希望查询执行的操作。如果你的意思是精确匹配，那么使用=。如果你的意思是模糊不清，那就用LIKE吧。说出你的意思通常是一个很好的代码政策。

Answer 14

在Oracle中，没有通配符的“like”将返回与“equals”相同的结果，但可能需要额外的处理。 According to Tom Kyte，Oracle在使用文字时会将没有通配符的“like”视为'equals'，但在使用绑定变量时则不会。

Answer 15

=和LIKE不一样;

1. =匹配确切的字符串
2. LIKE匹配可能包含通配符（％）
的字符串

Answer 16

= 比 LIKE 快得多。

在具有 11GB 数据和超过 1000 万条记录的 MySQL 上进行测试，f_time 列已编入索引。

SELECT * FROM XXXXX WHERE f_time = '1621442261' - 耗时 0.00 秒，返回 330 条记录

SELECT * FROM XXXXX WHERE f_time like '1621442261' - 耗时 44.71 秒，返回 330 条记录