有“额外的”数据库查询有多糟糕？

Question

我来自web开发的前端世界，在那里，我们非常努力地限制发出的HTTP请求的数量(通过合并css、js文件、图像等)。

对于db connections (MySQL)，显然您不希望有不必要的连接，但是通常情况下，多个小查询有多糟糕？(他们执行得很快)

我之所以问这个问题，是因为我要将我的应用程序移到集群环境中，在此之前，我在服务器内存中缓存一些东西(因为我运行在单个服务器上)，现在我正在尝试使我的应用程序“无状态”，而在我当前的实现中，这意味着更多的小db调用。这将帮助我进行负载平衡(避免棘手的会话)，并减少服务器内存的使用。

我们不是在谈论大量的查询，可能是6-8 db调用，而不是2-4，从少量记录返回到几千条记录。它们中的每一个都执行得很快，不到30 is (有些更少)，但是我不知道是否有一些“连接延迟”我应该关注。

谢谢你的洞察力。

Answer 1

简短的回答：(1)确保您保持在相同的大O级，重用连接，衡量性能；(2)考虑您对数据一致性的关心程度。

较长的答覆：

性能

严格地说，从性能的角度来看，除非您已经接近最大化数据库资源，例如max连接，否则这不太可能产生重大影响。但是有一些事情你应该记住：

• 替换"2-4“查询的"6-8”查询是否停留在相同的执行时间？例如，如果当前的数据库交互位于O(1)，那么它会变成O(n)吗？还是当前的O(n)将改为O(n^2)？如果是，您应该考虑一下这对您的应用程序意味着什么。
• 大多数应用程序服务器可以重用现有的数据库连接，或者具有持久的数据库连接池；确保应用程序不为每个查询建立新的连接；否则，这将使其效率更低。
• 在许多常见的情况下，主要是在具有复杂索引和联接的较大表上，通过主键执行很少的查询可能比在单个查询中连接这些表更有效；如果在执行这些连接时，服务器不仅要花费更长的时间来执行复杂查询，而且还要阻止针对受影响表的其他查询，则会出现这种情况。

一般来说，关于性能，经验法则是--总是衡量。

一致性

然而，性能并不是唯一需要考虑的方面。还可以考虑您有多关心应用程序中的数据一致性。

例如，考虑一个简单的案例表A和B，它们具有一对一的关系，并且使用主键查询单个记录。如果您加入这些表并使用单个查询检索结果，那么您将从A和B获得一条记录，或者没有任何记录，这也是您的应用程序所期望的。现在考虑一下，如果将其分成两个查询(而不是使用具有首选隔离级别的事务)--您可以从表A获得一个记录，但是在从表B获取匹配记录之前，它将被另一个进程删除/更新。现在，您的应用程序有来自A的记录，但没有来自B的记录。

这里的一般问题是-您是否关心关系数据的ACID遵从性，因为它与您正在分解的查询有关？如果答案是肯定的，则必须考虑应用程序逻辑在这些特定情况下的反应。

Answer 2

6-8查询一个网页？通常这样很好。我一直都这么做。

几千排回来了？卡住了！客户会拿那么多钱怎么办？SQL可以执行更多的处理，然后返回更少的行吗？

除了罕见的例外情况，每个网页只有一个连接。

每个查询都有很多开销。例如，将INSERTing 100行放入表中-- 100 INSERT单行语句将花费大约10倍于单个100行INSERT的时间。因此，当实际使用较少的往返到服务器。如果网络是广域网，这就变得非常重要。地球的另一边距离地球250毫秒，仅仅是为了延迟。同一数据中心中的服务器可能非常接近，因此可以忽略延迟。在广域网中，使用存储的例程来减少往返行程。

我喜欢在代码中主动地对每个查询进行计时。然后，如果我发现了性能问题，我将首先查看要处理的查询。或者使用SlowLog。