我正在建立一个网页,这是相当“昂贵”的数据库点击。我不想在这个阶段开始优化--尽管我试图达到最后期限,但我可能最终完全没有优化。
当前,页面需要18次(对18次)访问数据库。我已经在使用联接,其中一些查询是UNIONed,以尽量减少对数据库的访问。我的本地开发机器可以处理这个问题(页面并不慢),但是,我觉得如果我将其发布到野外,查询的数量将很快超过我的数据库(MySQL)。
我总是可以使用memcache或类似的东西,但我更愿意继续在截止日期之前完成我的其他开发工作--至少检索页面工作--这只是现在的优化问题(如果需要的话)。
因此,我的问题是--对于一个页面检索的18 db查询是否完全过分?(也就是说,我应该搁置所有内容并优化检索逻辑),还是我是否应该继续如常地继续,在截止日期之前发布并按计划发布,看看会发生什么?
编辑
为了澄清,我已经为查询中使用的字段使用了“明显”的索引(单索引和复合索引)。我还没有做的是运行一个查询分析器,看看我的索引等是否是最优的。
发布于 2010-06-05 12:51:01
18 db查询可能有点过分,除非它是某种复杂的门户;虽然不知道页面是什么和服务器后端代码,但很难判断。
额外查询的主要成本通常是为其建立数据库连接以及查询往返的成本。
对于前者,请确保后端支持数据库连接的共享池(我假设您使用PHP,所以我没有任何实用的建议,但Java和Perl都有实现这一点的方法);当然,确保一个页面加载对整个页面重用相同的DB连接。
对于后者(减去查询),请查看:
另外,考虑在webapp和DB (memcache,或缓存数据的应用服务器)之间设置一个中间层。
但是,我必须说,实际上,我建议不要做上述任何一件事,直到您用prod服务器和基准测试测试应用程序,并使用基准测试和概要分析找出慢点。
更新:要回答评论中的怀疑论者,这里有一些关于连接成本的信息,特别是与mysql相关的信息
http://mysql-dox.net/Sams-MySQL.Database.Design.and/0672327651/ch14lev1sec3.html (Google缓存)
发布于 2010-06-05 12:48:25
你的做法是完全错误的。
在这些“数据库之旅”中,人们注意到了一些不好的地方。
而且,您的调度会不惜任何代价将查询次数降到最低,这可能会导致查询速度减慢和性能灾难。
发布于 2010-06-16 17:19:28
您是否正在跨多个页面检索相同的信息?如果是的话,可能可以将该信息从一个页面传递到另一个页面,而不是每次查询DB。
例如,假设您在每个页面的顶部显示一个用户名(就像这样)。将此信息从一个页面传递到另一个页面可能更有意义,而不是每次都查询DB。我知道一个明显的例子,但我希望它能说明我想说的话。
https://stackoverflow.com/questions/2980359
复制相似问题