我是MySQL的新手，对我而言很快就会变得明显的是，每页创建几个数据库查询相对于其中一些数据库查询要容易得多....但我真的没有感觉有多少查询可能太多，或者在什么时候我应该投入更多宝贵的时间来组合查询，花时间找出聪明的联接等等。
因此，我想知道这里有经验丰富的人使用某种“心理基准”，每页的查询数量是多少，如果有的话，有多少可能太多了？
我理解在任何上下文中的正确答案都与满足应用程序功能需求所需的内容有关。但是，对于客户要求可能灵活或未正确设置的项目，或者您作为开发人员完全控制的项目（例如您自己开发的站点），您可以在功能和性能之间进行协商......基本上，如果编码要求影响性能并且您无法进一步优化它，那么只需切割琐碎的功能。
对此我表示感谢。
由于
答案 0 :(得分：21)
没有固定的数字，“页面”是足够随意的 - 一个可以做一个数据库任务，而另一个可以有二十几个小部件，每个小部件都有自己的任务。
一个好的经验法则是：当你把一个SELECT放在一个处理另一个SELECT行的循环中时，停止。它可能在早期看起来足够快，但数据趋于增长，并且那些嵌套循环将随之呈指数级增长，因此预计它会在某些时候成为瓶颈。即使单个查询最终变得非常慢，但从长远来看，你会更好（并且总是存储过程，查询缓存等）。
答案 1 :(得分：15)
这取决于页面的使用频率，应用服务器和数据库服务器之间的延迟以及许多其他因素。
对于只显示数据的页面，我的直觉是100太多了。但是，在某些情况下可以接受。
在实践中，您应该只在必要时进行优化，这意味着您可以优化人们最常使用的页面，而忽略次要页面。
特别是，这些页面不向公众开放，而且（很少）授权用户几乎不会使用它们，没有动力让它们更快。
如果您认为有太多查询存在真正的性能问题，请启用常规查询日志（这可能会使性能变差，我担心）并分析最常见的查询为了消除它们。
您可能会发现存在一些“低悬的成果” - 在大多数热门页面上调用很少更改数据的简单查询，您可以轻松消除这些数据（例如，让您的应用服务器获取cron作业上的数据）进入本地文件并从那里读取）。或者甚至是“较低的悬挂果实”，如完全没有必要的查询。
尝试组合多个查询的困难在于它往往会违反代码重用和代码可维护性，所以只有在绝对必要时才应该这样做;听起来你没有足够的数据来做出这个决定。