您预计大约能从价值 1000 美元的 MySQL 服务器中获得多少用处？

Question 1

正如你所说，这是一个非常宽泛的估计。

最大的问题是你用这 1000 美元买了什么。假设你花更多的内存和更少的处理器能力以及普通的硬盘，我会说一个合理编码的应用程序（合理 = 主要使用你的语言提供的任何抽象库）使用这些参数应该能够处理大约 500 个并发用户。除了行集的大小之外，我猜应该更多（因为直接放入 RAM 的行越多，即使是立即写入，你也需要访问磁盘的次数就越少）。

在这种情况下，行中的数据类型和您能够负担的 RAM 数量绝对是最重要的因素。如果您能够减少写入次数并降低索引表的大小，我认为您可能能够同时处理 1,000 个用户。

您将会看到两个问题：

您可以在 RAM 中缓存的数据量以及运行基本操作系统和数据库服务器操作所需的最低 RAM 量将决定您能承受什么。更多的 RAM、更少的操作系统需求以及应在 RAM 中保存用于查询和写入的更少有用数据量将意味着可接受的性能和大量抖动之间的差异。
应用程序的设计在这里绝对至关重要。一次写入涉及 500-1000 名用户会产生巨大影响。同样，如果您的调用不简单且高效，那么您很快就会导致灾难。我的估计基于我见过的大量 mySQL 应用程序，我对它们的工作原理知之甚少。如果应用程序存在基本问题，那么您甚至可能无法获得 40 个用户。如果您高效地编写代码并考虑到硬件限制，您可能能够轻松扩展到 2,000 以上。

Answer

正如你所说，这是一个非常宽泛的估计。

最大的问题是你用这 1000 美元买了什么。假设你花更多的内存和更少的处理器能力以及普通的硬盘，我会说一个合理编码的应用程序（合理 = 主要使用你的语言提供的任何抽象库）使用这些参数应该能够处理大约 500 个并发用户。除了行集的大小之外，我猜应该更多（因为直接放入 RAM 的行越多，即使是立即写入，你也需要访问磁盘的次数就越少）。

在这种情况下，行中的数据类型和您能够负担的 RAM 数量绝对是最重要的因素。如果您能够减少写入次数并降低索引表的大小，我认为您可能能够同时处理 1,000 个用户。

您将会看到两个问题：

您可以在 RAM 中缓存的数据量以及运行基本操作系统和数据库服务器操作所需的最低 RAM 量将决定您能承受什么。更多的 RAM、更少的操作系统需求以及应在 RAM 中保存用于查询和写入的更少有用数据量将意味着可接受的性能和大量抖动之间的差异。
应用程序的设计在这里绝对至关重要。一次写入涉及 500-1000 名用户会产生巨大影响。同样，如果您的调用不简单且高效，那么您很快就会导致灾难。我的估计基于我见过的大量 mySQL 应用程序，我对它们的工作原理知之甚少。如果应用程序存在基本问题，那么您甚至可能无法获得 40 个用户。如果您高效地编写代码并考虑到硬件限制，您可能能够轻松扩展到 2,000 以上。

Question 2

我可以回答这个问题。我刚刚下了车，还会再坐。

650-800 美元可以买到一台运行 1TB SATA2 硬盘的 8 GB RAM 中速四核 AMD 处理器。170 美元可以买到第二台相对较快的 1TB 硬盘。请记住，这是大多数电子产品/办公用品商店/百思买类地方的现成硬件。你可以在其他地方买到更划算的产品，但性价比不错。你可以多花一点钱买到更快的四核处理器。

现在，关于该应用程序，我假设您运行的是 linux/BSD/unix 操作系统，并避免 ms 与 unix 之争。以下是我发现的内容：

无论应用程序有多弱，我们都可以毫不费力地在任何应用程序上指定 200 多个活动用户/会话。事实上，我们已经运行了一段时间，在任何四核服务器上，应用程序都没有出现掉线/崩溃/停滞的情况……但我们在单核 200mhz 时代学到了一些教训。

例如，我们的姊妹公司销售了不少基于 mysql 的通信监控系统，每台机器有 1300 多名用户，平均每小时有数百个并发会话。记录和报告是实时完成的（当然，会出现一些缓冲），它们一直在 3Ghz 双核机器上运行，这些机器的 PATA 驱动器很慢……事实上，是 133Mhz P-ata 驱动器。最长的用户界面延迟约为 2 秒。十年前，他们放弃了 MSSQL，转而使用 MySQL，并立即取得了成果。

请记住，这些机器正在运行 webapps+databases....所以你算一下。它就是有效。此外，我已经用这些替换了许多 oracle/MS/xxxx 应用程序，并且从未耗尽过动力。此外，让我从 dba 的角度扩展一下另一个人所说的内容...以下是来自实践的 6 条提示。

写入将降低性能，特别是当锁定惩罚对您的程序员来说是一个陌生的概念时。
在一张大桌子上做所有事情会让你筋疲力尽。
过度规范化不是你的朋友。如果你的程序员完全遵循第三范式，你的应用程序将运行得很糟糕。非规范化的数据占用更多空间，但可以通过简单的查询完成伟大的事情。
一个大表会因频繁写入而阻塞。参见 1。
如果您编写应用程序以使用一个（或多个）表来显示数据，并使用另一个表来执行写入操作（当系统负载允许时，该表可以同步到读取表），那么您就可以解决各种问题。我们使用少量表来缓冲写入，并且能够处理数量惊人的事务，因为没有人受到干扰。
使用索引。如果您知道查询的哪些部分用作键，那就使用索引。
根据内存调整数据库安装。请参阅在线 MySQL 文档。说实话，如果您的活动会话少于 1000 个，您通常只需增加连接数即可。 http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html

通过查看大多数 wordpress/etc. 插件，您可以看到愚蠢的 SQL 正在发挥作用。大多数插件都是由不懂 SQL 的人编写的，只需少数几个用户，它们就会在短时间内使服务器瘫痪。

Answer