有"额外"的数据库查询有多糟糕?

Bri*_*ald 5 mysql database coldfusion database-performance lucee

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

使用数据库连接(MySQL),显然你不希望有不必要的连接,但作为一般规则,有多个小查询有多糟糕?(他们执行得很快)

我问,因为我正在将我的应用程序移动到集群环境中以及在我在服务器内存中缓存一些内容之前(因为我在单个服务器上运行),我现在正试图使我的应用程序"无状态"并且在我当前实现意味着更小的db调用.这将帮助我实现负载平衡(避免粘性会话)并降低服务器内存使用率.

我们不是在谈论大量的查询,可能是6-8个db调用而不是2-4个调用,从少量记录返回到几千个记录.它们中的每一个都快速执行,不到30ms(一些更少),但我不知道是否存在一些我应该关注的"连接延迟".

感谢您的见解.

Uni*_*One 6

简短回答:(1)确保你保持在同一个大O级别,重用连接,衡量绩效; (2)想一想你对数据一致性的关注程度.

答案很长:

性能

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

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

一般而言,关于表现,经验法则是 - 总是衡量.

一致性

但是,性能不是唯一需要考虑的方面.还要考虑您对应用程序中数据一致性的关注程度.

例如,考虑一个简单的案例 - 表A并且B具有一对一的关系,并且您使用主键查询单个记录.如果你加入这些表,并使用一个单一的检索查询结果,你要么获得无论从记录AB,或不从任何记录,这是你的应用程序需要什么了.现在考虑是否将其拆分为2个查询(并且您没有使用具有首选隔离级别的事务) - 您从表中获取记录A,但在您从表中获取匹配记录之前B,它将被另一个进程删除/更新.现在你的应用程序有一个记录,A但没有来自B.

这里的一般问题是 - 您是否关心您的关系数据的ACID合规性,因为它与您正在分离的查询有关?如果答案是肯定的,那么您必须考虑应用程序逻辑在这些特定情况下的反应.


Ric*_*mes 5

一个网页有 6-8 个查询?通常这很好。我一直这样做。

返回了数千行?呛!客户要用这么多做什么?SQL 能否进行更多处理,然后返回更少的行?

除极少数例外,每个网页只有 1 个连接。

每个查询都有很大的开销。例如,INSERTing表中包含 100 行 - 100 个INSERT单行语句所需的时间大约是单个 100 行语句的 10 倍INSERT。因此,在实际使用时,可以减少与服务器的往返次数。如果网络是 WAN,这一点就变得非常重要。地球的另一边有 250 毫秒的距离,只是延迟而已。同一数据中心中的服务器可能非常接近,以至于可以忽略延迟。在 WAN 中,使用存储例程来最大程度地减少往返次数。

我喜欢在代码中主动计时每个查询。然后,如果我发现性能问题,我会首先查看要处理哪个查询。或者使用 SlowLog。