我正在整理一个网页，该网页在数据库命中率方面相当“昂贵”。我不想在这个阶段开始优化 - 尽管我试图赶在最后期限之前，但我最终可能根本不会优化。
目前该页面需要 18 次(正确的 18 次)点击数据库。我已经在使用连接，并且一些查询被联合起来以最小化对数据库的访问。我的本地开发机器可以处理这个(页面不慢)但是，我觉得如果我将它发布到野外，查询的数量将很快淹没我的数据库(MySQL)。
我总是可以使用内存缓存或类似的东西，但我更愿意继续我的其他需要在截止日期前完成的开发工作——至少检索页面工作——现在只是一个优化问题(如果需要) .
因此，我的问题是 - 单页检索的 18 db 查询是否完全令人发指 -(即我应该搁置所有内容并优化检索逻辑)，或者我应该照常继续，在截止日期前发布按计划进行，看看会发生什么？
[编辑]
澄清一下，我已经完成了“显而易见”的事情，例如对查询中使用的字段使用(单一和复合)索引。我还没有做的是运行查询分析器来查看我的索引等是否是最佳的。
最佳答案
18 db 查询可能有点矫枉过正，除非它是某种复杂的门户；虽然不知道 100% 页面是什么和服务器后端代码，但很难判断。
额外查询的主要成本通常是为其建立数据库连接以及查询往返的成本。
对于前者，请确保您的后端支持共享数据库连接池(我假设您使用 PHP，所以我没有任何实用的建议，但 Java 和 Perl 都有实现这一点的方法)；当然，还要确保一个页面加载对整个页面重复使用相同的数据库连接。
对于后者(查询较少)，请查看:
将所有查询捆绑到具有多个结果集的单个大型查询
像您已经做的那样，通过 JOIN 和 UNION 对结果集进行反规范化
另外，考虑在您的网络应用和数据库(内存缓存，或缓存数据的应用服务器)之间设置一个中间层。
但是，我必须说，实际上，我建议不要执行上述任何操作，直到您针对生产服务器和基准测试应用程序并使用基准和分析找到慢点。
更新:为了回答评论中的怀疑论者，这里有一些关于连接成本的信息，特别是与 mysql 相关的信息
http://mysql-dox.net/Sams-MySQL.Database.Design.and/0672327651/ch14lev1sec3.html ( Google cache )
关于mysql - 网页数据库查询优化，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2980359/