SQL Join与没有Join的代码中的单独查询 - 性能

时间:2009-12-10 19:19:32

标签: sql performance join

我想知道这两个选项之间是否真的有性能提升:

选项1:

  • 我使用连接执行SQL查询以选择所有用户及其排名。

选项2:

  • 我执行一个SQL查询来选择所有用户
  • 我获取所有用户并执行另一个SQL查询以获取此用户的排名。

在代码中,选项二对我来说更容易实现。这只是因为我设计我的持久层的方式。

所以,我想知道对性能有什么影响。在我有什么限制之后我应该考虑采用选项1而不是选项2?

4 个答案:

答案 0 :(得分:13)

一般来说,DB服务器在加入时总是比应用程序代码更快。请记住,对于每个联接,您必须使用网络往返进行额外查询。但是,如果您的第一个结果集很小并且索引调整得很好,则此模型可以正常工作。

如果你只是为了重新使用你的ORM解决方案,那么你可能正在打一场失败的战斗。我总是发现我需要只能用SQL生成的只读数据集,因此我现在将ORM用于每个对象的CRUD操作,并将常规SQL用于搜索,报告,聚合等。

答案 1 :(得分:1)

如果排名是静态值,请考虑在应用程序中缓存它们。

如果您经常需要用户并且很少排名,请考虑延迟加载排名。 (例如,单独的查询,但第二个查询仅偶尔使用)。

如果您总是需要两组数据,请使用联接,并且它们必须是数据库的当前副本。

对任何可能的选择进行原型设计,并运行性能测试。

编辑:关于你的持久层的进一步想法,因为我自己也面对这个问题。考虑添加“类似持久性”的类来处理连接作为其基本查询,并且是只读的。这是否适合您的特定方案由您决定,但许多应用程序的许多数据库访问都基于连接,这可能相当大且复杂。如果您能够以持久的可更新对象以一致的方式处理这些对象,那么它对您的整体架构来说可能是一个巨大的胜利。从概念上讲,它很像在数据库中拥有一个视图,并查询视图而不是编写连接,但是你在代码中完成所有操作。

答案 2 :(得分:0)

这取决于您预期的用户数量。选项一肯定会更快,但如果数据量合理,差异可以忽略不计。

答案 3 :(得分:0)

在99%的情况下,加入会更快。

然而,有一种罕见的情况可能会变慢。如果你正在进行一对多的连接,那么大行的大小就会达到网络带宽限制。

例如,在T1中有1MB大小的blob列,您正在加入T2,每个T1行包含100行。结果集将是T1行数100。

因此,如果您通过连接查询一个T1行,则结果将为100MB,如果您获取T1行(1MB),然后单独选择为此T1获取100 T2,则结果集将为1MB。