多个数据库访问还是一个大规模访问？

关于性能和最佳资源利用的更好方法是：通过AJAX多次访问数据库以仅在需要时获取所需的确切信息，或者执行一次访问以检索包含所有可能需要的信息的对象。，很有可能实际上并不需要全部吗？

我知道如何对实际查询进行基准测试，但是当成千上万的用户同时访问数据库时，我不知道如何测试数据库性能方面的最佳选择，以及连接池如何发挥作用。

没有一个正确的答案。像任何优化一样，它很大程度上取决于上下文/用法。

但是，请根据以下原则进行考虑：

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

记住优化的第一条规则：测量，不要猜测。尝试两者，并使用某种秒表代码为它们进行检测，然后查看花费更长的时间。

还要记住一个古老的笑话，即“计算机科学中只有两个困难的问题：缓存无效和命名问题。” 如果您一次从数据库中提取所有内容并将其保存在内存中，那么您将拥有一个缓存。现在，您遇到了一个新问题：无论何时在系统中的任何地方进行任何更改，它都必须在两个位置进行相同的更改：数据库和缓存。如果您有多个服务器在与数据库进行通信，或者有多个API可以使服务器修改数据，那么这将变得非常棘手。

没有银弹解决这个问题。我想您需要尝试可能的折衷方案，并调整服务器以获得最佳性能。

第一点：开始进行任何改进之前，您需要设置当前的性能基准，对其进行衡量，并以此为基准，比较可能的解决方案以进行改进。

第二件事是，需要跟踪应用程序的使用情况。最终用户利用应用程序的方式。减少最终用户不需要的返回的数据原始数量可以节省大量宝贵的服务器资源。例如：当用户对前50条记录感兴趣时，返回5000条记录毫无意义。

第三点：您必须了解呼叫的频率和可能的影响。例如：如果大多数调用都是查找值表查询，那么您可能会创建一个基础结构来缓存这些调用。换句话说，如果您的数据不经常更改，请考虑使用缓存选项。当然，尽量减少通话次数应有助于提高性能。

一次获得所有内容将为您带来更好的性能，除非“所有内容”都包含BLOB或类似的大型数据对象之类的东西。序列化所有内容，通过网络进行传输，然后在另一端进行反序列化的性能开销相当大，其中网络延迟是其中很大的一部分。内存比网络带宽便宜，并且可能会保留一段时间。您唯一真正的答案将来自基准测试，但是如果您只是试图对一个进行评估，那就是我要依靠的方法。

如果您要做出体系结构决策，那么REST是一种选择。使用REST，您总是会多次请求资源，即，您不会发送获取2个对象的请求，因为每个对象都有自己的URL。使用HTTP / 2.0时，解决此样式的性能问题可能会得到解决。否则，您只需进行优化即可使其尽可能快。许多公司都这样做。