"extra" 数据库查询有多糟糕？
how bad is it to have "extra" database queries?
我来自 Web 开发的前端世界，我们非常努力地尝试限制发出的 HTTP 请求的数量（通过合并 css、js 文件、图像等）。
使用数据库连接 (MySQL)，显然您不希望有不必要的连接，但作为一般规则，有多个小查询有多糟糕？ （他们执行得很快）
我问是因为我正在将我的应用程序移动到集群环境，之前我在服务器内存中缓存一些东西（因为我在单个服务器上 运行），我现在正在尝试我的应用程序 "stateless" 在我当前的实现中，这意味着更多的小型数据库调用。这将帮助我实现负载平衡（避免粘性会话）并降低服务器内存使用率。
我们说的不是大量查询，可能是 6-8 次 db 调用而不是 2-4 次，返回从几条记录到几千条记录的任何地方。每一个都执行的很快，不到30ms（有的少很多），但是不知道有没有"connection latency"值得关注的
感谢您的见解。
简短回答：(1) 确保您保持在相同的大 O 级别、重用连接、衡量性能； (2) 想想你有多关心数据的一致性。
长答案：
性能
严格从性能的角度来看，一般来说，除非您已经接近用尽数据库资源（例如最大连接数），否则这不太可能产生重大影响。但有些事情你应该记住：
- 替换“2-4”查询的“6-8”查询是否保持相同的执行时间？例如如果当前数据库交互处于
O(1) 是否会更改为 O(n)？或者当前的 O(n) 将更改为 O(n^2)？如果是，您应该考虑这对您的应用程序意味着什么
- 大多数应用服务器可以重用现有的数据库连接，或者拥有持久的数据库连接池；确保您的应用程序不会为每个查询建立新连接；否则这将使它变得更加低效
- 在许多常见情况下，主要是在具有复杂索引和连接的较大 table 上，通过主键进行少量查询可能比在单个查询中连接这些 table 更有效；如果在执行此类连接时，服务器不仅需要更长的时间来执行复杂查询，而且还会阻止其他针对受影响 tables
的查询，就会出现这种情况
一般而言，关于性能，经验法则是 - 始终衡量。
一致性
但是，性能并不是唯一需要考虑的方面。还要考虑一下您对应用程序中数据一致性的关心程度。
例如，考虑一个简单的情况 - tables A 和 B 具有一对一关系，并且您正在使用主键查询单个记录.如果您加入这些 table 并使用单个查询检索结果，您将从 A 和 B 获得记录，或者两者都没有记录，这就是您的应用程序太期待了现在考虑是否将其拆分为 2 个查询（并且您没有使用具有首选隔离级别的事务）——您从 table A 获得了一条记录，但在您可以从 table B，被另一个进程deleted/updated。现在您的应用程序有来自 A 的记录，但来自 B.
的 none
这里的一般问题是 - 您是否关心关系数据的 ACID 合规性，因为它与您正在分解的查询有关？如果答案是肯定的，您必须考虑您的应用程序逻辑在这些特定情况下将如何反应。
一个网页有 6-8 个查询？通常这很好。我经常这样做。
数千行 return？呛！客户要用那么多做什么？ SQL 可以做更多的处理，然后 return 更少的行吗？
除极少数情况外，每个网页只有 1 个连接。
每个查询都有很多开销。例如，将 INSERTing 100 行放入 table -- 100 INSERT 单行语句所花费的时间大约是单个 100 行 INSERT 的 10 倍。因此，在可行的情况下 减少与服务器的往返次数。如果网络是 WAN，这就变得非常重要。地球的另一边有 250 毫秒的距离，只是为了延迟。同一数据中心中的服务器可能非常接近，以至于可以忽略延迟。在 WAN 中，使用存储例程来最大程度地减少往返。
我喜欢在代码中主动为每个查询计时。然后，如果我发现性能问题，我会查看首先处理哪个查询。或者使用 SlowLog。
我来自 Web 开发的前端世界，我们非常努力地尝试限制发出的 HTTP 请求的数量（通过合并 css、js 文件、图像等）。
使用数据库连接 (MySQL)，显然您不希望有不必要的连接，但作为一般规则，有多个小查询有多糟糕？ （他们执行得很快）
我问是因为我正在将我的应用程序移动到集群环境，之前我在服务器内存中缓存一些东西（因为我在单个服务器上 运行），我现在正在尝试我的应用程序 "stateless" 在我当前的实现中，这意味着更多的小型数据库调用。这将帮助我实现负载平衡（避免粘性会话）并降低服务器内存使用率。
我们说的不是大量查询，可能是 6-8 次 db 调用而不是 2-4 次，返回从几条记录到几千条记录的任何地方。每一个都执行的很快，不到30ms（有的少很多），但是不知道有没有"connection latency"值得关注的
感谢您的见解。
简短回答：(1) 确保您保持在相同的大 O 级别、重用连接、衡量性能； (2) 想想你有多关心数据的一致性。
长答案：
性能
严格从性能的角度来看，一般来说，除非您已经接近用尽数据库资源（例如最大连接数），否则这不太可能产生重大影响。但有些事情你应该记住：
- 替换“2-4”查询的“6-8”查询是否保持相同的执行时间？例如如果当前数据库交互处于
O(1)是否会更改为O(n)？或者当前的O(n)将更改为O(n^2)？如果是，您应该考虑这对您的应用程序意味着什么 - 大多数应用服务器可以重用现有的数据库连接，或者拥有持久的数据库连接池；确保您的应用程序不会为每个查询建立新连接；否则这将使它变得更加低效
- 在许多常见情况下，主要是在具有复杂索引和连接的较大 table 上，通过主键进行少量查询可能比在单个查询中连接这些 table 更有效；如果在执行此类连接时，服务器不仅需要更长的时间来执行复杂查询，而且还会阻止其他针对受影响 tables 的查询，就会出现这种情况
一般而言，关于性能，经验法则是 - 始终衡量。
一致性
但是，性能并不是唯一需要考虑的方面。还要考虑一下您对应用程序中数据一致性的关心程度。
例如，考虑一个简单的情况 - tables A 和 B 具有一对一关系，并且您正在使用主键查询单个记录.如果您加入这些 table 并使用单个查询检索结果，您将从 A 和 B 获得记录，或者两者都没有记录，这就是您的应用程序太期待了现在考虑是否将其拆分为 2 个查询（并且您没有使用具有首选隔离级别的事务）——您从 table A 获得了一条记录，但在您可以从 table B，被另一个进程deleted/updated。现在您的应用程序有来自 A 的记录，但来自 B.
这里的一般问题是 - 您是否关心关系数据的 ACID 合规性，因为它与您正在分解的查询有关？如果答案是肯定的，您必须考虑您的应用程序逻辑在这些特定情况下将如何反应。
一个网页有 6-8 个查询？通常这很好。我经常这样做。
数千行 return？呛！客户要用那么多做什么？ SQL 可以做更多的处理，然后 return 更少的行吗？
除极少数情况外，每个网页只有 1 个连接。
每个查询都有很多开销。例如，将 INSERTing 100 行放入 table -- 100 INSERT 单行语句所花费的时间大约是单个 100 行 INSERT 的 10 倍。因此，在可行的情况下 减少与服务器的往返次数。如果网络是 WAN，这就变得非常重要。地球的另一边有 250 毫秒的距离，只是为了延迟。同一数据中心中的服务器可能非常接近，以至于可以忽略延迟。在 WAN 中，使用存储例程来最大程度地减少往返。
我喜欢在代码中主动为每个查询计时。然后，如果我发现性能问题，我会查看首先处理哪个查询。或者使用 SlowLog。