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

Posted 2023-02-25

【中文标题】在 PHP 中，每页有多少个 DB 调用是可以的？

【英文标题】：In PHP, how many DB calls per page is okay?

【发布时间】：2010-09-27 03:12:30

【问题描述】：

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

【问题讨论】：

我很想以“主观和争论”来结束它。这个问题的意义何在？

这是一个完全正确的问题。

一个干净的 WP 安装请求大约 20 个公共页面加载查询。对我来说太多了，对其他人来说还可以。

【参考方案1】：

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

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

总体而言，查看数据库调用的一个好方法是确定特定页面是否在可接受的时间内加载，然后从那里查看优化加载时间以及 cpu 和内存使用的策略。

【参考方案2】：

一根绳子有多长？男人的腿应该多长？您应该在页面加载时进行多少数据库查询？

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

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

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

【参考方案3】：

请记住，100,000 个页面请求在 24 小时内仅每秒超过 1 个。只要他们不立即请求。

【参考方案4】：

别忘了

使用存储过程 - 它们运行得更快。 以新鲜方式运行它们 - 每周一次。 （数据库使用其当前状态优化存储过程。如果这种情况发生变化，则存储过程将停止优化）。 使用诸如“显示计划”之类的命令来真正了解您的 SP 正在做什么。 存储的过程可以返回多个数据集（数据表），这减少了网络流量。一个存储过程可以做多种事情。

托尼

【参考方案5】：

除了缓存之外，另一个重要的事情是使用准备好的语句。当您执行查询时，数据库必须 1) 分析查询并 2) 执行它。如果使用prepared statements，db可以缓存上次使用的查询计划，这样每次查询对dbms的负担就会更小。不要计算执行多少查询的负载，而要计算对 dbms 施加的压力。执行 100 个准备好的查询比执行 50 个在代码中临时生成的查询要快。

【讨论】：

我认为这在这种情况下不会有丝毫不同 - 分析查询可能不是问题。我宁愿怀疑它是到数据库的往返，查询本身可能相当容易

【参考方案6】：

当我在 .com 热潮中从事 www.boxman.com 项目时，他们有一个网站，在不同的域下显示为 9 个不同的语言/国家/地区网站。每一条文本都是从数据库中提取的，以及产品等通常的东西……每个页面通常会涉及 200 个奇数的数据库请求，但主要返回一个 id、string 组合。我们的系统一次有 100 个用户。

DB 在 16 路 RS6000 unix 机器上运行 DB2 SQL。这可能相当于现代的 3ghz QUAD 核心英特尔盒。

系统工作...随着卷的增加，我实现了一个缓存，其中涉及编写一个同步过程，该过程将每天的静态数据移动到网络服务器的驱动器，因此它不再访问数据库。

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

【参考方案7】：

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

如果您可以在单个查询中返回多个结果集，请执行此操作。如果信息是相当静态的，则将其缓存并从缓存中提取。

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

【讨论】：

组合多个查询不仅会使源代码复杂化，而且通常比执行多个简单调用的效率低。 SQL_CALC_FOUND_ROWS 是一个完美的例子——在除了琐碎的数据集之外的任何东西上，在两个单独的查询中计数和检索都更快。聪明并不总是更好

最好尽可能少地往返数据库。这始终是这个问题的答案。

【参考方案8】：

我会说这取决于服务器负载。如果您每分钟有 1 个访问者，那么每页 1-10 db 调用就可以了。如果您的服务器负载高于此值，例如每秒 10 个页面请求，那么您应该考虑缓存以最小化您的数据库服务器上的负载。

【参考方案9】：

这实际上取决于您的 (db) 服务器设置。尽量缓存大部分信息并将数据库调用减少到最低限度。数据库将（几乎在所有情况下）成为您服务的瓶颈——您的网站使用率越高。所以无论你做什么都尽量避免触发查询，好像不是真的必要一样。

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

【参考方案10】：

我认为您当前的查询数量是可以的，只要服务器（网络和数据库）可以处理您的所有请求并在可接受的时间内返回页面。它在很大程度上取决于服务器。 尽管如此，使用尽可能少的查询是一个很好的规则。

【讨论】：

实际给出的数字无处可寻。这取决于服务器的使用方式，而不是服务器的马力。

我想他是说不管数字是多少，只要数据库能在一个好的时间范围内处理它就可以了。