除了通配符，=和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 '

Using MS SQL Server 2012, the trailing spaces will be ignored in the comparison, except with LIKE when the column type is VARCHAR. Using MySQL 5.5, the trailing spaces will be ignored for =, but not for LIKE, both with CHAR and VARCHAR. Using PostgreSQL 9.1, spaces are significant with both = and LIKE using VARCHAR, but not with CHAR (see documentation). The behaviour with LIKE also differs with CHAR. Using the same data as above, using an explicit CAST on the column name also makes a difference: SELECT 'CAST none', val FROM testtable WHERE char_name LIKE 'A' UNION ALL SELECT 'CAST both', val FROM testtable WHERE CAST(char_name AS CHAR) LIKE CAST('A' AS CHAR) UNION ALL SELECT 'CAST col', val FROM testtable WHERE CAST(char_name AS CHAR) LIKE 'A' UNION ALL SELECT 'CAST value', val FROM testtable WHERE char_name LIKE CAST('A' AS CHAR) This only returns rows for "CAST both" and "CAST col".

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

如果要搜索精确匹配，可以同时使用，=和LIKE。

在这种情况下，使用“=”稍微快一点(搜索精确匹配)——你可以自己检查，在SQL Server Management Studio中进行两次相同的查询，一次使用“=”，一次使用“LIKE”，然后使用“查询”/“包括实际执行计划”。

执行这两个查询，您应该会看到两次结果，以及两个实际的执行计划。在我的例子中，它们被分割成50%对50%，但是“=”执行计划有一个更小的“估计子树成本”(当你将鼠标悬停在最左边的“SELECT”框上时显示)-但是，这真的不是一个巨大的差异。

但是当你开始在LIKE表达式中使用通配符进行搜索时，搜索性能将会下降。搜索“LIKE Mill%”仍然可以相当快- SQL Server可以使用该列的索引，如果有一个。搜索“LIKE %expression%”非常慢，因为SQL Server能够满足此搜索的唯一方法是执行全表扫描。所以点赞时要小心!

Marc

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

最好的祝福……

取决于数据库系统。

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

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

例如，在MySQL中，字符串上的=默认情况下总是不区分大小写的，所以没有特殊字符的LIKE是一样的。在其他一些RDBMS上，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条记录