左连接优于内连接？

Question

我一直在分析我正在处理的应用程序中的一些查询，我遇到了一个查询，它检索的行数超过了必要的行数，结果集在应用程序代码中被缩减。

将 LEFT JOIN 更改为 INNER JOIN 会将结果集修剪为所需的内容，并且可能还会提高性能（因为选择的行更少）。实际上，LEFT JOIN'ed 查询的性能优于 INNER JOIN'ed，只需一半的时间即可完成。

LEFT JOIN：（总共 127 行，查询耗时 0.0011 秒）

INNER JOIN：（总共 10 行，查询耗时 0.0024 秒）

（我多次运行查询，这些都是平均值）。

在两者上运行 EXPLAIN 无法解释性能差异：

对于 INNER JOIN：

id  select_type     table   type    possible_keys   key     key_len     ref        rows     Extra
1   SIMPLE  contacts        index       NULL        name        302     NULL         235    Using where
1   SIMPLE  lists           eq_ref      PRIMARY     PRIMARY     4   contacts.list_id     1   
1   SIMPLE  lists_to_users  eq_ref      PRIMARY     PRIMARY     8   lists.id,const  1    
1   SIMPLE  tags            eq_ref      PRIMARY     PRIMARY     4   lists_to_users.tag_id   1    
1   SIMPLE  users           eq_ref      email_2     email_2     302     contacts.email 1    Using where

对于左连接：

id  select_type     table   type    possible_keys   key     key_len     ref     rows    Extra
1   SIMPLE          contacts index      NULL        name        302     NULL    235     Using where
1   SIMPLE        lists     eq_ref      PRIMARY     PRIMARY     4   contacts.list_id    1    
1   SIMPLE    lists_to_users eq_ref     PRIMARY     PRIMARY     8   lists.id,const  1    
1   SIMPLE         tags     eq_ref      PRIMARY     PRIMARY     4   lists_to_users.tag_id   1    
1   SIMPLE        users     eq_ref      email_2     email_2     302     contacts.email  1   

还有查询本身：

SELECT `contacts`.*, `lists`.`name` AS `group`, `lists`.`id` AS `group_id`, `lists`.`shared_yn`, `tags`.`name` AS `context`, `tags`.`id` AS `context_id`, `tags`.`color` AS `context_color`, `users`.`id` AS `user_id`, `users`.`avatar` 
FROM `contacts`  
LEFT JOIN `lists` ON lists.id=contacts.list_id  
LEFT JOIN `lists_to_users` ON lists_to_users.list_id=lists.id AND lists_to_users.user_id='1' AND lists_to_users.creator='1'  
LEFT JOIN `tags` ON tags.id=lists_to_users.tag_id 
INNER JOIN `users` ON users.email=contacts.email 
WHERE (contacts.user_id='1') 
ORDER BY `contacts`.`name` ASC

（我所说的子句是'users'表上的最后一个INNER JOIN）

查询在 MySQL 5.1 数据库上运行，如果有影响的话。

有没有人知道为什么在这种情况下 LEFT JOIN 的查询优于 INNER JOIN 的查询？

更新：由于 Tomalak 建议我使用的小表使 INNER JOIN 更加复杂，我创建了一个包含一些模拟数据的测试数据库。 'users' 表是 5000 行，contacts 表是 ~500,000 行。结果是一样的（时间也没有改变，当您考虑到现在的表要大得多时，这令人惊讶）。

我还在联系人表上运行了 ANALYZE 和 OPTIMIZE。没有任何明显的区别。

Answer 1

如果你认为 LEFT JOIN 的实现是 INNER JOIN + 更多的工作，那么这个结果是令人困惑的。如果 INNER JOIN 的实现是（LEFT JOIN + 过滤）呢？啊，现在清楚了。

在查询计划中，唯一的区别是：users... extra: using where。这意味着过滤。带有内部连接的查询中有一个额外的过滤步骤。

---

这是一种不同于通常在 where 子句中使用的过滤。在 A 上创建索引以支持此过滤操作很简单。

SELECT *
FROM A
WHERE A.ID = 3

考虑这个查询：

SELECT *
FROM A
  LEFT JOIN B
  ON A.ID = B.ID
WHERE B.ID is not null

这个查询相当于内连接。 B 上没有索引可以帮助过滤操作。原因是 where 子句声明了连接结果的条件，而不是 B 上的条件。

Answer 2

这可能是由于 INNER JOIN 必须检查两个表中的每一行以查看列值（在您的情况下为电子邮件）是否匹配。 LEFT JOIN 无论如何都会从一张表中返回所有内容。如果它被编入索引，那么它也会知道该做什么更快。

Answer 3

表基数对查询优化器有影响。我猜小表，因为你有使内部连接更复杂的操作。一旦您的记录多于数据库服务器愿意保留在内存中的记录，内连接可能会开始优于左连接。

Answer 4

imo 您正在陷入被称为过早优化的陷阱。查询优化器是非常变化无常的东西。我的建议是继续前进，直到您确定某个特定连接存在问题为止。

Answer 5

试试这个：

SELECT `contacts`.*, `lists`.`name` AS `group`, `lists`.`id` AS `group_id`, `lists`.`shared_yn`, `tags`.`name` AS `context`, `tags`.`id` AS `context_id`, `tags`.`color` AS `context_color`, `users`.`id` AS `user_id`, `users`.`avatar` 
FROM `contacts`  
INNER JOIN `users` ON contacts.user_id='1' AND users.email=contacts.email
LEFT JOIN `lists` ON lists.id=contacts.list_id  
LEFT JOIN `lists_to_users` ON lists_to_users.user_id='1' AND lists_to_users.creator='1' AND lists_to_users.list_id=lists.id
LEFT JOIN `tags` ON tags.id=lists_to_users.tag_id 
ORDER BY `contacts`.`name` ASC

这应该会给您带来额外的性能，因为：

• 您将所有内连接放在出现任何“左”或“右”连接之前。这会在应用后续外连接之前过滤掉一些记录
• “AND”运算符的短路（“AND”的顺序很重要）。如果列和字面值的比较为假，则不会执行所需的表扫描以查找表 PK 和 FK 之间的比较

如果您没有发现任何性能改进，则将所有列集替换为“COUNT(*)”并进行左侧/内部测试。这样，无论查询如何，您都将仅检索 1 个单行和 1 个单列（计数），因此您可以放弃返回的字节数是导致查询缓慢的原因：

SELECT COUNT(*)
FROM `contacts`  
INNER JOIN `users` ON contacts.user_id='1' AND users.email=contacts.email
LEFT JOIN `lists` ON lists.id=contacts.list_id  
LEFT JOIN `lists_to_users` ON lists_to_users.user_id='1' AND lists_to_users.creator='1' AND lists_to_users.list_id=lists.id
LEFT JOIN `tags` ON tags.id=lists_to_users.tag_id 

祝你好运

Answer 6

LEFT JOIN 返回的行数比 INNER JOIN 多，因为这两个不同。
如果 LEFT JOIN 在它正在查找的表中没有找到相关条目，它将为该表返回 NULL。
但如果 INNER JOIN 没有找到相关条目，则根本不会返回整个行。

但是对于您的问题，您是否启用了 query_cache ？ 尝试使用

运行查询

SELECT SQL_NO_CACHE `contacts`.*, ...

除此之外，我会用更多数据填充表格，然后运行

ANALYZE TABLE t1, t2;
OPTIMIZE TABLE t1, t2;

看看会发生什么。