什么时候优化性能为时已晚？
我知道你不应该太早优化，而应该以可维护性为目标。我的问题是，什么时候为时已晚？
我正在开发一个网站，类似于雅虎答案，我的数据库结构正是我认为应该的。 用户、问题、答案、question_comments、answer_comments等表格
。问题是，如果网站要增长，这个架构将如何扩展？我正在考虑将问题和答案放在一个表中（posts），按类型分隔它们，然后将 Question_comments 和answer_comments 放在同一个表中（comments ）。我相信这与 stackoverflow 的 DB 方案类似。
我知道你们会说：“在它成为实际问题之前不要担心”。但到那时再担心是不是有点太晚了？
谢谢
I know that you shouldnt optimize too early, and you should instead aim for maintainability. My question is, at what point is it too late?
I'm working on a website, similar to yahoo answers, and my database structure is exactly what I feel it should be. Table for users, questions, answers, question_comments, answer_comments, etc.
My question is, IF the site were to grow, how would this architecture scale? I'm thinking of putting both questions and answers in a single table (posts), separating them by type, and then putting both question_comments and answer_comments in the same table (comments). I believe this is similar to stackoverflow's DB scheme.
I know what you guys are gonna say, "Dont worry about it until it becomes an actual problem". But wouldn't it be a little too late to worry about it then?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
尽早优化是一种不好的做法，因为在您的网站出现大量流量之前，您不知道瓶颈在哪里。目前，您的用户如何访问您的网站并与之交互尚不清楚。
几乎总是最好从一个“好的”架构（规范化数据库、MVC 架构、DRY、编写良好的前端代码等）开始，然后从那里开始。扩展一个干净、有组织的架构比过早优化的架构要容易得多。
现在最好的情况是您可以通过 ab 或其他负载进行一些负载测试测试工具来查看您当前的瓶颈在哪里。它当然不会找到全部，但会找到一些。
如果您真的担心这个（而且您不应该担心），请安装 Nagios 或 Munin 在您的服务器上监控性能。使用第三方工具每天测量页面加载时间。一旦您开始发现问题，您就可以进行分析和调整。
The reason why it's a bad practice to optimize early is you don't know where your bottlenecks will be until your website sees a significant amount of traffic. How your users access and interact with your site is an unknown at this point.
It's almost always best to start with a 'good' architecture (normalized database, MVC architecture, DRY, well-written frontend code, etc) and go from there. It will be much easier to scale a clean, organized architecture than one that was prematurely optimized.
At best right now you can do some load testing via ab or another load testing tool to see where your current bottlenecks are. It certainly won't find all of them, but it will find some.
If you're really worried about this (and you shouldn't be yet), install Nagios or Munin on your server to monitor performance. Use a third party tool to measure page load time daily. Once you start seeing issues then you can profile and tune.
如果快速服务是应用程序的基本要求，那么您绝对应该进行优化。
如果不需要亚秒级响应，那么您可以编写干净的代码并稍后进行优化。
一个很好的例子就是在最新版本的浏览器出现之前的 JavaScript，那些为页面编写漂亮、干净、可扩展的 JS 的人却表现得很糟糕，不得不从头开始。
You absolutely should optimize if a fast service is a fundamental requirement of the application.
If sub-second responses are not a requirement, than you can write clean code and optimize later.
A good example of this was JavaScript before the latest version of browsers, people who wrote nice, clean, extensible JS for their pages had terrible performance and had to start from scratch.
一张巨大的表通常更难维护。人们通常将表分割成分区，甚至将数据库分割成分片。
我不明白将所有评论放入同一个表中会如何为您节省连接。实际上，将问题和答案放入同一个表中也不会为您节省连接，您只是通过同一个表进行连接。
如果您想节省连接，我希望您使用面向文档的 NoSQL 数据库，例如 MongoDB。您可以在其中将问题以及所有相关答案和评论存储在单个“记录”中，只需一次操作即可获取。
One huge table is generally harder to maintain. People usually cut their tables into partitions and even their databases into shards.
I don't see how putting all comments into the same table would save you a join. Really, putting questions and answers into the same table won't save you a join either, you'll just be joining by the same table.
If you want to save on joins, I'd expect you use a document-oriented NoSQL database, such as MongoDB. That's where you can store a question with all related answers and comments in a single 'record', fetchable with one operation.
数据库的设计需要考虑性能，而不是等到以后出现问题时才考虑。过早的优化并不意味着不在设计中进行优化，而是意味着不要过度优化。然而，每个数据库后端都有已知的性能杀手，如果您熟悉一种不同的技术会更快并且需要相同的时间来编写代码，那么设计使用其中一种是愚蠢的。因此，在设计任何数据库之前，请先阅读有关性能调优的内容，您将永远不会再以相同的方式编写数据库代码。
Databases need to be designed with performance in mind not wait until you havea problem later. Premature optimization doesn't mean don't do it in design, it means don't get ridiculously excessive about it. However, there are known performance killers for every database backend and it is foolish to design to use one of those when a differnt technique will be faster and take the same amount of time to write code for if you are familar with it. So before designing any database, read up on performance tuning and you will never write database code the same way again.