在PHP中，每个页面可以调用多少个DB？

我已经在一个灯上设置了共享主机。显然，每页对Db的调用越少越好。但是有多少是太多了？两个？十个？一百？好奇人们的想法。

我认为只要服务器（web和数据库）能够处理您的所有请求并在可接受的时间内返回页面，您当前的查询数量就可以了。它在很大程度上依赖于服务器。

---

无论如何，使用尽可能少的查询是一个好规则。

这实际上取决于（db）服务器的设置。尽量缓存大部分信息，并将数据库调用减少到最低限度。数据库（几乎在任何情况下）都会成为您服务的瓶颈——您的站点使用率越高。因此，无论您做什么，都要尽量避免引发一个似乎并非真正必要的查询

---

我尽量不使用每页超过10 db的调用，但这实际上取决于您的基础结构和您想要提供的信息。

我认为这取决于服务器负载。如果您每分钟有1个访问者，那么每页1-10 db的呼叫就可以了。如果你的服务器负载高于那个，比如说每秒10页的请求，那么你应该考虑缓存来最小化你的DB服务器上的负载。

总是最好的。两个通常是一个太多

如果可以在一个查询中返回多个结果集，那么就这样做。如果信息相当静态，则缓存它并从缓存中提取

---

10个单独的数据库调用是不好的，但它不会杀死一个低使用率的站点

当我在.com热潮中参与www.boxman.com项目时，他们有一个网站，在不同的领域下出现了9个不同的语言/国家网站。每一段文字都是从数据库中提取出来的，还有产品等常见的东西。。。每个页面通常涉及200多个DB请求，但主要返回单个id、字符串组合。我们一次在系统上有100个用户

DB在16路RS6000 unix机器上运行DB2 SQL。这可能相当于现代的3ghz四核intel机箱

系统工作正常。。。随着卷数的增加，我实现了一个缓存，其中包括编写一个同步进程，将每天静态的数据移动到Web服务器的驱动器中，使其不再访问数据库

---

基本上，我会说，如果性能好，那就好了！但您应该考虑到需求的扩大，并在需求发生时做好准备。

除缓存之外的另一个重要事项是使用准备好的语句。执行查询时，数据库必须1）分析查询，2）执行查询。如果使用准备好的语句，db可以缓存上次使用的查询计划，因此每个查询对dbms的负担较小。不要计算您执行了多少查询，而是计算您对dbms施加了多少压力。执行100个准备好的查询可能比执行50个在代码中临时生成的查询要快。

别忘了

使用存储过程-它们运行得更快

一周一次，用新鲜的水冲洗。（数据库使用其当前状态优化存储过程。如果此更改，则存储过程将停止优化）

使用诸如“show plan”之类的命令来真正了解SP正在做什么

存储的进程可以返回多个数据集（数据表），这减少了网络流量。一个存储过程可以做多种事情

---

Tony

记住，在24小时内，100000个页面请求仅每秒超过1次。只要他们不立刻提出要求。

一根绳子有多长？一个人的腿应该有多长？在一次页面加载中应该进行多少个DB查询

没有单一的答案。显然，进行不必要的查询是个坏主意。启动过多的DB连接甚至更糟糕。缓存不变的值是好的。除此之外，你不能在一个页面上武断地说“你应该只使用$N个查询”，这取决于你想做什么&你的性能目标是什么

理论上，任何应用程序都可以编写为使用单个DB查询，即使该查询是一个大规模的20路连接，涉及未索引的完整表扫描并返回数千行，这些行大部分为空，一旦到达应用程序，将需要大量内存和时间来处理。显然，这将是一件非常糟糕的事情。一般来说，避免做明显浪费的事情（比如在循环中执行一堆单行查询），并担心以后的性能

---

用Donald Knuth的话说，“我们应该忘记小效率，比如说97%的时间：过早优化是万恶之源”。每个人都在谈论“可伸缩性”，好像他们真的会成为下一个Twitter，但事实上，如果Twitter专注于像现在这样大，他们可能永远不会一开始就推出产品。

最终将取决于用户期望的体验。如果他们希望在页面上显示全面的数据，那么必须有一些期望：1.）考虑到从数据库中提取的数据量，站点将能够在负载下运行；2.）加载页面的时间成本将取决于该特定页面的数据负载，而不是在整个服务器负载上

db调用的可接受数量的巨大支持者必须是底层db设计。有一些企业级的电子商务网站，由于底层数据库结构的复杂性，每个（未缓存的）页面加载通常会进行100次以上的调用

---

总的来说，查看db调用的一个好方法是确定特定页面是否在可接受的时间内加载，并从中查看优化加载时间、cpu和内存使用的策略。

我很想以“主观且有争议”来结束这一点。问题的重点是什么？这是一个完全正确的问题。一个干净的WP