ORM选择n + 1个性能；加入或不加入

Question

也有类似的问题，但我认为没有人问过这个特定问题。

设想：

客户-订单（其中订单具有客户ID）-OrderPart-部件

我想要一个查询，该查询返回具有其所有订单以及每个订单及其零件的客户。

现在，我有两个主要选择：

1. 使用嵌套循环（产生单独的查询）
2. 使用数据加载选项（产生单个查询联接）

问题：

关于ORM的大多数建议和示例都建议使用选项2，我可以理解为什么。但是，选项2可能会发送回大量重复的数据，例如：

Option 1 results (3 queries):

ID  Name       Country
1   Customer1  UK

ID  Name
1   Order1
2   Order2

ID  Name
1   Part1
2   Part2
3   Part3

Option 2 results (1 query):

ID  Name       Country  ID  Name    ID Name
1   Customer1  UK       1   Order1  1  Part1
1   Customer1  UK       1   Order1  2  Part2
1   Customer1  UK       1   Order1  3  Part3
1   Customer1  UK       2   Order2  1  Part1
1   Customer1  UK       2   Order2  2  Part2

选项1发送带有3个查询的13个字段。选项2在1个查询中发回42个字段。现在，假设客户表有30个字段，而订单具有更复杂的子联接，则数据重复会迅速变得庞大。

以下各项会对整体性能产生什么影响：

• 建立数据库连接的开销
• 发送数据所花费的时间（如果在其他服务器上，则可能跨网络）
• 带宽

选项2始终是最佳选择，选项1是最佳选择还是取决于情况？如果需要，应使用什么标准来确定？是否有足够的ORM聪明地自己解决？

Answer 1

建立数据库连接的开销

如果它们位于通常的同一子网中，则很少。如果不是，那么这仍然不是很大的开销，可以通过大多数ORM拥有的缓存来克服（NHibernate具有第一级和第二级缓存）。

发送数据所花费的时间（如果在其他服务器上，则可能跨网络）

因为SELECT N+1这显然会更长，因为每次都必须发送select语句，最长可能长达1k。它还必须从池中获取新的连接。在2002年至2003年间，使用Chatty和矮胖的说法一直是争论的焦点，但是除非这是一个非常大的应用程序，否则现在并没有太大的不同，在这种情况下，您可能希望有经验的（或薪水更高的）专家来发表他的观点。
-即顾问。

但是，我希望加入连接，因为数据库将在其10或10多年的开发过程中针对这种用法进行优化。如果性能确实很慢，则View可以解决此问题或存储过程。

顺便说一句，SELECT N+1这可能是人们在首次使用NHibernate时（包括我自己）遇到的最常见的性能问题，而这实际上是需要进行调整才能解决的。这是因为NHibernate对ORM而言就像C
++对语言一样。

带宽

SELECT每个对象的额外语句Customer最终将建立许多Customer对象* Orders。因此，对于大型系统而言，这可能很明显-
但正如我提到的那样，ORM通常具有适当的缓存机制来消除此问题。SELECT考虑到以下事实，语句的数量也不会那么大：

• 大多数情况下，您与SQL Server处于同一网络上
• 增加的字节数大约会带来额外的0.5-50k的额外带宽？想一想大多数服务器上的速度有多快。