blocks|key|2319059|text|这实际上取决于您的(Db)服务器设置。尽量缓存大多数信息，并将db调用减少到最少。数据库将(几乎在任何情况下)成为你的服务的瓶颈--你的站点的使用率越高。因此，无论您做什么，都要尽量避免触发查询，如果不是真的需要的话。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2319060|我尽量不要在每个页面上使用超过10个db调用，但这真的取决于您的基础架构和您想要提供的信息。|2319061|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

That really depends on your (db)servers setup. Try to cache most of information as possible and reduce db calls to a minimum. A database will (almost in every case) be the bottleneck of your service - the higher the usage of your site. So whatever you do try to avoid fireing a query as if not really necessary.

I try not to use more than 10 db calls per page, but that really depends on your infrastructure and the information you want to provide.

blocks|key|3398754|text|我会说这取决于服务器负载。如果你每分钟有一个访问者，那么每页1-10个db调用就足够了。如果您的服务器负载高于该值，例如每秒10个页面请求，那么您应该考虑使用缓存来最小化数据库服务器上的负载。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3398755|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I would say that depends on the server load. If you have 1 visitor per minute, then 1-10 db calls per page would be just fine. If your server load is higher than that, say 10 page requests per second, then you should consider caching to minimize the load on your db server.

blocks|key|404209|text|当我在.com热潮中从事www.boxman.com项目时，他们有一个网站，在不同的域名下显示为9种不同的语言/国家/地区的网站。每一段文本都是从数据库中提取出来的，以及产品等常见的东西。每个页面通常会涉及200多个DB请求，但主要返回单个id、字符串组合。我们在系统上一次有100个用户。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|404210|DB在16路RS6000+unix机器上运行DB2+SQL。这可能等同于现代的3+3ghz四核英特尔盒。|404211|系统工作了..。随着卷的增加，我实现了一个缓存，这涉及到编写一个同步过程，将每天静态的数据移动到was服务器的驱动器上，这样它就不再命中数据库。|404212|基本上我会说，如果性能是可以的，那么它就是可以的！但你应该考虑到需求的扩大，并在需求扩大时做好准备。|404213|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

When I worked on the www.boxman.com project in the .com boom, they had one website that appeared as 9 different language/country sites under different domains. Every piece of text was pulled from the DB as well as usual things like products etc... Each page typically would involve 200 odd DB requests, but mainly returning a single id,string combo. We had 100 of users on the system at a time.

The DB ran DB2 SQL on a 16 way RS6000 unix box. This is probably equivient to a modern day 3ghz QUAD core intel box.

The system worked... as volumes picked up I implemented a cache which involved writing a sync process that moved data that was static on a daily basis to the webserver's drive so it no longer hit the DB.

Basically I would say if performance is okay then it's okay! but you should allow for expanding demand and be ready for it when it happens.

blocks|key|5510628|text|我认为，只要服务器(web和数据库)能够处理您的所有请求并在可接受的时间内返回一个页面，那么您当前的查询次数是可以接受的。它在很大程度上依赖于服务器。无论如何，使用尽可能少的查询是一个好的规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5510629|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think your current number of queries is okay as long as the servers (web and database) can handle all your requests and return a page in a acceptable time. It depends on the servers to a large scale.
Nevertheless using as few queries as possible is a good rule anyways.

blocks|key|2314495|text|一根绳子有多长？男人的腿应该有多长？一次页面加载应该进行多少个DB查询？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2314496|没有唯一的答案。显然，进行不必要的查询不是一个好主意。启动过多的数据库连接甚至更糟。缓存不变的值是很好的。除此之外，您不能在页面上随意地说“您应该只使用$N查询”--这取决于您要做什么&您的性能目标是什么。|2314497|从理论上讲，任何应用程序都可以编写为使用单个数据库查询-即使该查询是一个大型20向连接，该连接涉及未索引的全表扫描并返回数千行，这些行大多为空，一旦到达应用程序，将占用大量的内存和时间进行处理。显然，这将是一件非常糟糕的事情。通常，避免做明显浪费的事情(比如在循环中做一堆单行查询)，并在以后担心性能。|2314498|用Donald+Knuth的话说：“我们应该忘记小效率，说大约97%25的时间:过早优化是一切邪恶的根源”。每个人都在谈论“可伸缩性”，好像他们真的会成为下一个Twitter，但实际上，如果Twitter专注于像现在这样大的规模，他们可能从一开始就不会推出一个产品。|2314499|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

How long is a piece of string? How long should a man's legs be? How many DB queries should you make on a page load?

There's no single answer. Obviously, making unnecessary queries is a bad idea. Starting excessive DB connections is even worse. Caching unchanging values is good. Beyond that, you can't really arbitrarily say "You should only use $N queries" on a page - it depends on what you're trying to do &amp; what your performance goals are.

In theory, any application could be written to use a single DB query - even if that query is a massive 20-way join involving unindexed full table scans and return thousands of rows that are mostly nulls that would take ridiculous ammount of memory and time to process once it gets to your application. Clearly, this would be a Very Bad Thing. In general, avoid doing things that are obviously wasteful (like doing a bunch of single-row queries in a loop) and worry about performance later.

In the words of Donald Knuth "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil". Everyone talks about 'scalability' like they're really going to be the next Twitter but, in reality, if Twitter had focused on being as big as they are now, they probably never would've gotten a product out the door in the first place.

blocks|key|5510984|text|它最终将取决于你的用户期望的体验。如果他们希望在页面上显示全面的数据，则必须有一定的期望1。)考虑到从数据库提取的数据量，该站点将能够在负载下运行，以及2)。加载页面的时间开销将取决于该特定页面的数据负载，而不是整个服务器负载。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5510985|一个可以接受的数据库数量的巨大支持者也必须是底层数据库设计。由于底层数据库结构的复杂性，有些企业级电子商务网站通常会对每个(未缓存的)页面负载进行超过100次的调用。|5510986|总而言之，查看db调用的一个好方法是确定特定页面是否在可接受的时间量内加载，并从那里查看优化加载时间以及cpu和内存使用的策略。|5510987|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

It is ultimately going to end up depending upon what experience your user is expecting. If they are expecting comprehensive data to show up on the page, there has to be some expectation that 1.) The site will be able to function under load, given whatever amount of data is being drawn from the db, and 2.) the time-cost of loading the page is going to be dependent upon the data-load for that particular page, and not on the overall server load. 

A huge proponent of what an acceptable number of db calls is has to be the underlying db design, as well. There are enterprise-grade e-commerce sites out there that regularly make upwards of 100s of calls per (uncached) page load, just due to the complexities of the underlying db structure.

Overall, a good way to look at db calls is to determine whether a particular page loads in an acceptable amount of time, and from there look at strategies to optimize load time and cpu and memory usage.

blocks|key|2319138|text|除了缓存之外，另一个重要的事情是使用预准备语句。当您执行查询时，db必须1)分析查询并2)执行它。如果使用预准备语句，则数据库可以缓存上次使用的查询计划，因此每次查询对dbms的负担较小。不要计算执行了多少查询的负载，而要计算对dbms施加了多大的压力。执行100个准备好的查询可能比执行在代码中临时生成的50个查询更快。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2319139|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Another important matter except for caching is to use prepared statements. When you execute a query, the db has to 1) analyze the query and 2) execute it. If you use prepared statements, the db can cache the query plan it used last time, so each query will be a smaller burden on the dbms. Don't count the load in how many queries you execute, but how much stress you put on the dbms. Executing 100 prepared queries can be faster than executing 50 queries generated ad-hoc in the code.

blocks|key|407134|text|记住，100,000个页面请求在24小时内每秒只有1个多一点。只要他们都不是一次请求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|407135|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

remember 100,000 page requests is only just over 1 a second over 24 hours. As long as they all don't request at once.

blocks|key|2314459|text|别忘了|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2314460|2314461|使用存储的进程-它们运行得更快。|ordered-list-item|offset|length|style|BOLD|2314462|以全新的方式运行它们-每周一次。(数据库使用其当前状态优化存储的过程。如果这种情况发生变化，则存储过程将停止优化)。|2314463|使用诸如"show+plan“之类的命令来真正了解您的SP正在做什么。|2314464|存储过程可以返回多个数据集(数据表)，这将减少网络流量。一个存储的进程可以做多件事。|2314465|2314466|托尼|2314467|entityMap^0|0|0|0|G|0|0|1M|0|0|Z|0|0|16|0|0|0|2|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|Z|8|@$F|10|G|11|H|I]]|9|@]|A|$]]|$1|L|3|M|5|E|7|12|8|@$F|13|G|14|H|I]]|9|@]|A|$]]|$1|N|3|O|5|E|7|15|8|@$F|16|G|17|H|I]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|19|8|@$F|1A|G|1B|H|I]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|T|$]]

Don't forget

<ol>
<li>use stored procs - they run faster.</li>
<li>run them in fresh - once a week. (the database optimizes stored procs using its current state. If this changes then the store process will stop being optimial).</li>
<li>use commands like "show plan" to really understand what your SPs are doing.</li>
<li>Stored procs can return multiple datasets (datatables) this cuts down on network traffic. A single stored proc can do multiple things.</li>
</ol>

Tony

blocks|key|2319099|text|一个或更少总是最好的。两个通常是多了一个。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2319100|如果您可以在一个查询中返回多个结果集，那么就这么做吧。如果信息是相当静态的，那么将其缓存并从缓存中提取。|2319101|10个单独的数据库调用是不好的，但它不会杀死一个低使用率的网站。|2319102|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

One or less is always best. Two is usually one too many. 

If you can return multiple result sets in a single query, then do it. If the information is fairly static, then cache it and pull from cache. 

10 separate database calls is not good, but its not going to kill a low usage site.

I've got shared hosting on a LAMP set up. Obviously the fewer calls to the Db per page the better. But how many is too many? Two? Ten? A hundred? Curious what people think.

In PHP, how many DB calls per page is okay?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我已经在台灯上设置了共享主机。显然，每页对Db的调用越少越好。但是有多少才算太多呢？二?十?一百?好奇人们在想什么。

问在PHP中，每个页面有多少个DB调用是可以的？
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在PHP中，每个页面有多少个DB调用是可以的？EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在PHP中，每个页面有多少个DB调用是可以的？
EN