使用IN进行JOIN或INNER SELECT，哪个更快？

Question

我想知道使用IN进行INNER JOIN或INNER SELECT哪个更快？

select t1.* from test1 t1
inner join test2 t2 on t1.id = t2.id
where t2.id = 'blah'

要么

select t1.* from test1 t1
where t1.id IN (select t2.id from test2 t2 where t2.id = 'blah')

Answer 1

假设id是关键，这些查询的含义是相同的，一个不错的DBMS将以完全相同的方式执行它们。 不幸的是，MySQL没有这样做，可以通过在此SQL Fiddle中扩展“查看执行计划”链接来看到。 哪一个会更快取决于表的大小-如果TABLE1行很少，则IN有机会更快，而JOIN在所有其他情况下都可能更快。

这是MySQL查询优化器的独特之处。 我从未见过Oracle ， PostgreSQL或MS SQL Server以不同的方式执行这种简单的等效查询。

Answer 2

如果您不得不猜测， INNER JOIN可能比IN (SELECT ...)效率更高，但是从一个查询到另一个查询可能有所不同。

EXPLAIN关键字是您最好的朋友之一。 在完整的SELECT查询前面输入EXPLAIN ，MySQL将为您提供有关如何执行查询的一些基本信息。 它会告诉您在何处使用文件排序，在何处使用已创建的索引（以及在何处忽略它们）以及可能需要检查多少行才能满足请求。

如果其他所有条件都相同，则主要使用INNER JOIN因为它更容易预测，因此对于新来的开发人员来说更容易理解。但是，当然，如果您看到IN (SELECT ...)表单的真正优势，请使用它！

Answer 3

尽管您必须在查询的任何RDBS上检查执行计划，但我认为inner join会更快或至少相同。 如果我错了，也许有人会纠正我。

无论如何，嵌套选择很可能会运行整个内部查询，并从test2构建可能值的哈希表。 如果该查询返回一百万行，则无论如何都要承担将数据加载到内存中的费用。

使用内部联接，如果test1仅具有2行，则可能只需在test2进行2次索引扫描以获取这些行中每行的id值，而不必将一百万行加载到内存中。

更为现代的数据库系统也有可能优化第一种情况，因为它在每个表上都有统计信息，但是在最佳情况下，内部联接将是相同的。

Answer 4

在大多数情况下，JOIN比子查询快得多，但是子查询比JOIN更具可读性。

RDBMS针对JOIN创建执行计划，因此可以预测应该加载哪些数据进行处理。 这绝对可以节省时间。 另一方面，对于子查询，它运行所有查询并加载所有数据以进行处理。

有关更多详细信息，请检查此链接。