我正在写一个商业计划，我必须模拟成本，当我的网站将达到500.000独特的访问者。
访问者：500.000浏览量：1,500,000蜘蛛浏览量：500,000浏览量：2,000,000
每页有50个查询+ –
每天查询：每小时100百万：每分钟4百万：每秒70,000：1,200峰值：3,000
做这个计算我需要3000个查询第二个…什么样的服务器可以处理它？
问题是：实际上，我的网站每天有2000次访问，而且每秒有+ 150/200次查询…从这一点开始，我预计每秒会有50,000个查询。
在集群或复制中需要多less台服务器来pipe理这项工作？
谢谢西蒙
我曾经为一家电子商务公司工作，网站每天有数百万次的点击量。 我们有一个DELL PE 1750，带有2个单核CPU和2GB的RAM，数据库大小约为。 4GB。 在高峰时间，这台服务器每秒处理高达5万个查询。
话虽如此：数据库结构良好，所有查询都进行了精细调整（我们每周都会分析慢速查询日志并修复查询和索引），并对服务器设置进行了微调。 caching绝对是一个好主意，但是无论如何，MySQL只需要分析性能，然后调整内存的使用方式（查询caching与其他选项）即可。
从这个经验我可以告诉你，最大的影响是由缺less索引，错误的索引和错误的数据库devise（例如长string字段作为主键和类似的废话）造成的。
这完全取决于查询的复杂程度，服务器有多less内存以及磁盘有多快。
如果查询非常简单，或者非常适合，那么单个大型数据库服务器就可以处理这个问题。 但是，如果查询非常复杂（或简单但调整不当），则需要多台服务器。
如果不知道你正在运行的具体查询，数据库scheme和大小，这个估计是不可能的。
索引列上的一个简单的SELECT与一些基于非索引的JOIN 非常不同…当然，如果涉及的表包含1Klogging或1M，事情会发生很大的变化。
也：
正如Ignacio所说，你可能想要考虑caching。 在cms或者甚至在堆栈前面。 每个（每个！）页面的50多个查询确实是很多。
根据你的评论来看，最大的因素将是你的数据集的大小，或者至less是“热门”数据集的大小。 只要服务器很less去磁盘来满足查询，在16核心服务器上的3,000qps甚至8,000qps也不是问题。 一旦活动数据集超过了InnoDB用来caching的内存量，性能就会迅速下降。
对于大型的“热门”数据集，转换为“大数据”scheme可能是值得的投资，这是他们的目标。 例如，如果您有大量的数据需要检索，但是您永远不会重写，而只能追加新的数据，请查看Apache Hive。 浏览一下，它们通常是一种可以轻松地与现有代码进行交互的风格，也可以防止耗尽高速caching空间的胃灼热。