我正在整理一个在数据库命中方面非常“昂贵”的网页。我不想在这个阶段开始优化 - 虽然在我试图达到最后期限的时候，我可能最终都没有优化。
目前该页面需要18个（这是正确的十八个）命中数据库。我已经在使用连接，并且一些查询是UNIONed以最小化到db的行程。我的本地开发机器可以处理这个（页面不慢）但是，我觉得如果我将它释放到野外，查询的数量将很快压倒我的数据库（MySQL）。
我总是可以使用memcache或类似的东西，但我更愿意继续我的其他开发工作，需要在截止日期之前完成 - 至少检索页面工作 - 它只是现在优化的问题（如果需要）
因此我的问题是 - 对单页检索的18分析查询是完全离谱的 - （即我应该把所有东西都搁置并优化检索逻辑的地狱），或者我将继续正常，满足截止日期并发布按计划看看会发生什么？
[编辑]
为了澄清，我已经完成了“明显”的事情，比如对查询中使用的字段使用（单一和复合）索引。我还没有做的是运行查询分析器来查看我的索引是否是最佳的。
答案 0 :(得分：0)
你的方法完全错了。
这些“前往数据库”的行程并不是很糟糕。
您可以不惜一切代价最大限度地减少查询数量，这可能会导致您减慢查询速度和性能灾难
答案 1 :(得分：0)
额外查询的主要成本通常是为其建立数据库连接以及查询往返的成本。
对于前者，请确保您的后端支持共享数据库连接池（我假设您使用PHP，因此我没有任何实用建议，但Java和Perl都有实现这一目标的方法）;当然要确保一个页面加载重用整个页面的相同数据库连接。
对于后者（减少查询），请查看：
将所有查询捆绑到一个包含多个结果集的大型查询
通过JOIN和UNION取消规范化结果集，就像您已经做的那样
另外，请考虑在您的webapp和数据库（memcache或缓存数据的应用服务器）之间建立中间层。
但是，我必须说实际上，我建议不要执行上述任何操作，直到您针对prod服务器和基准测试应用程序，并使用基准测试和分析找到慢点。
更新：要回答评论中的怀疑论者，这里有关于连接成本的一些信息，特别是与mysql相关的信息
http://mysql-dox.net/Sams-MySQL.Database.Design.and/0672327651/ch14lev1sec3.html （Google cache）
答案 2 :(得分：0)
您是否在多个页面中检索相同的信息？如果您是这样，可以将该信息从一个页面传递到另一个页面，而不是每次都查询该数据库。
例如，假设您在每个页面的顶部显示用户名（如SO所示）。将这些信息从一个页面传递到另一个页面可能更有意义，而不是每次都在查询数据库。我知道一个明显的例子，但我希望它能说明我想说的话。
答案 3 :(得分：0)
18个查询不是问题，只要它们快速有效。
然而，如果你觉得这个太多了，也许你应该看看更大的图片并确定该页面是否试图做太多。