我组建了一个网页，这是在数据库访问方面相当“昂贵”。 我不想开始在这个阶段优化 - 尽管我试图打一个期限，我可能最终没有优化的。
目前，页面需要18个（这是正确的为18个）命中的分贝。 我已经使用联接和一些疑问被合并，以尽量减少前往分贝。 如果我释放到野外这是我的本地开发机可以处理这个问题（页不慢），但是，我觉得，查询的数量将迅速压倒我的数据库（MySQL的）。
我总是可以使用内存缓存或类似的东西，但我宁愿用我需要在最后期限之前完成其他开发工作继续 - 至少在检索页面的作品 - 它只是优化的问题，现在（如果需要）。
我的问题因此 - 是一个单一的页面检索18分贝查询完全离谱 - （即我应该把一切都保持和优化检索逻辑的地狱），或我将继续为正常，满足最后期限并释放进度和走着瞧吧？
[编辑]
只是为了澄清，我已经做了“明显的”之类的使用（单一和复合）指标在查询中使用的字段。 我还没有做的是运行一个查询分析器，看看我的索引等是最优的。
18分贝查询可能是有点大材小用的，除非它是某种复杂的门户网站; 虽然不知道100％的页面是什么，服务器的后端代码是很难判断。
额外的查询的主要成本通常是建立它的数据库连接，以及查询往返的成本。
对于前者，请确保您的后端支持共享数据库连接池（我假设你使用PHP，所以我没有任何实际的建议，但Java和Perl都有实现这一目标的方式）; 当然要确保一个页面加载重用整个页面相同的数据库连接。
对于后者（少查询），看看：
捆绑所有的查询与多个结果集的单个大型查询
通过JOIN和UNION像你已经做德正常化您的结果集
此外，考虑让你的web应用和DB（内存缓存，或者缓存数据的应用程序服务器）之间的中间层。
但是，我必须说，实际上，我建议不要做任何以上的，直到你对测试服务器督促和基准测试应用程序，并找到使用基准和分析的慢了点。
更新：要回答在评论怀疑论者，这里的一对连接的成本一些信息，具体相关OT的MySQL
http://mysql-dox.net/Sams-MySQL.Database.Design.and/0672327651/ch14lev1sec3.html （ 谷歌缓存 ）
你的做法是完全错误的。
还有就是注意在这些“旅行的分贝”不好。
而你attemts，以尽量减少在任何费用查询号码可能会导致你慢查询和性能灾难
你检索所有在多个页面相同的信息？ 如果你是有可能通过网页的各种信息，而不是每次查询数据库。
例如，假设你在每一页（像这样做）的顶部显示用户名。 它可能更有意义，从页面每次将此信息传递给页面，而不是查询数据库的吧。 一个明显的例子类，我知道，但我希望它证明什么，我想说的。
18个查询是没有问题的，只要它们是快速，高效。
但是，如果你觉得实在是太多了，也许你应该看看更大的照片并决定是否该网页正在试图做太多。
