mysql - "extra"数据库查询有多糟糕？

Question

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

对于数据库连接 (MySQL)，显然您不希望有不必要的连接，但作为一般规则，有多个小查询有多糟糕？ (他们执行迅速)

我问是因为我正在将我的应用程序移动到集群环境中，之前我在服务器内存中缓存一些东西(因为我在单个服务器上运行)，我现在试图让我的应用程序“无状态”并且在我当前的实现中，这意味着更多的小型数据库调用。这将帮助我实现负载平衡(避免粘性 session )并降低服务器内存使用率。

我们不是在谈论大量查询，可能是 6-8 次 db 调用而不是 2-4 次，返回从几条记录到几千条记录的任何地方。它们每个都执行得很快，不到 30 毫秒(有些更短)，但我不知道是否存在一些我应该担心的“连接延迟”。

感谢您的见解。

Answer 1

简短回答:(1) 确保您保持在相同的大 O 级别、重用连接、衡量性能； (2) 想想你有多关心数据的一致性。

长答案:

性能

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

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

一般而言，关于性能，经验法则是 - 始终衡量。

一致性

但是，性能并不是要考虑的唯一方面。还要考虑您对应用程序中数据一致性的关心程度。

例如，考虑一个简单的情况 - 具有一对一关系的表 A 和 B 并且您正在使用主键查询单个记录。如果您连接这些表并使用单个查询检索结果，您将同时从 A 和 B 获得记录，或者两者都没有记录，这就是您的应用程序也期望。现在考虑是否将其拆分为 2 个查询(并且您没有使用具有首选隔离级别的事务)——您从表 A 中获取了一条记录，但在您从表 中获取匹配记录之前code>B，它被另一个进程删除/更新。现在您的应用程序有来自 A 的记录，但没有来自 B 的记录。

这里的一般问题是 - 您是否关心关系数据的 ACID 合规性，因为它与您要拆分的查询有关？如果答案是肯定的，您必须考虑您的应用程序逻辑在这些特定情况下将如何 react 。