mysql – 拥有“额外”数据库查询有多糟糕?

前端之家收集整理的这篇文章主要介绍了mysql – 拥有“额外”数据库查询有多糟糕?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

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

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

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

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

感谢您的见解.

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

答案很长:

性能

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

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

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

一致性

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

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

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

猜你在找的MySQL相关文章