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

最好的祝福……

在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

这是我对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是一样的。

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

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