SQL JOIN查询比较

Question

以下解释来自本书：图形数据库。Robinson、Ian、Jim Webber和Emil Eifrem。在"奥莱利传媒，股份有限公司"，2013年。

---

假设有两个表：

人员

ID, Person
1, Alice  
2, Bob  
..,..  
99, Zach 

个人好友

ID, Person 
1, 2   
2, 1  
2, 99  
..,..  
99,1

示例2-1。Bob的朋友

SELECT p1.Person 
FROM Person p1 
JOIN PersonFriend   
ON PersonFriend.FriendID = p1.ID  
JOIN Person p2  
ON PersonFriend.PersonID = p2.ID  
WHERE p2.Person = 'Bob'    

根据我们的样本数据，答案是爱丽丝和扎克。这不是一个特别昂贵或困难的查询，因为它使用过滤器WHERE Person.perse='Bob'.来限制所考虑的行数

友谊并不总是一种反射性关系，因此在示例2-2中，我们询问对等查询，即"谁是Bob 的朋友">

示例2-2。谁是鲍勃的朋友？

SELECT p1.Person 
FROM Person p1 
JOIN PersonFriend  
ON PersonFriend.PersonID = p1.ID 
JOIN Person p2
ON PersonFriend.FriendID = p2.ID 
WHERE p2.Person = 'Bob'

这个问题的答案是爱丽丝；遗憾的是，扎克并不认为鲍勃是他的朋友。这种交互查询仍然很容易实现，但在数据库方面，它的成本更高，因为数据库现在必须考虑PersonFriend表中的所有行。我们可以添加一个索引，但这仍然涉及到一个昂贵的间接层。

---

上面的一切都来自这本书，不是我的意见。我不明白的是
1(为什么示例2-2中的查询比示例2-1中的查询更贵
2(为什么它被称为互惠查询？

Answer 1

1. 我看到的唯一会影响性能的是如何定义索引
   情况1:您唯一的索引是(PersonID, FriendID)。我认识的所有DB都会创建B树索引作为默认索引，并且能够单独在PersonID上使用它进行搜索。结果：零件ON PersonFriend.PersonID = p2.ID WHERE p2.Person = 'Bob'可能会使用它并且速度很快。对于第二个查询，情况并非如此
   情况2:您有两个独立的索引，(PersonID)和(FriendID)列各有一个。在这种情况下，这两个查询在性能方面是等效的(它们只使用每个索引(。

2. 不要把交互查询当作一个技术术语，因为事实并非如此。
   作者只是颠倒了JOIN。在第一个查询中，FriendID出现在第一个，PersonID出现在第二个。这就给出了答案：鲍勃喜欢谁
   相反，第二个查询首先对PersonID进行联接，其次对FriendID进行联接。这就给出了答案：谁喜欢鲍勃？(也就是说：友谊是相互的吗(