在性能开始降低之前，MySQL数据库可以获得多大的性能？
MySQL数据库在什么时候开始失去性能？
- 物理数据库大小是否重要？
- logging的数量是多less？
- 任何性能下降是线性的还是指数性的？
我有我认为是一个大型的数据库，大约有15Mlogging，几乎2GB。 根据这些数字，是否有任何激励我清理数据，或者我可以安全地让它继续扩展几年？
物理数据库的大小并不重要。 logging的数量并不重要。
根据我的经验，您要运行的最大问题不是大小，而是您一次可以处理的查询数量。 最有可能的是你将不得不移动到一个主/从configuration，以便读取查询可以运行在奴隶和写查询运行对主。 但是，如果你还没有准备好，你可以随时调整你正在运行的查询的索引，以加快响应时间。 另外，你可以对Linux中的networking堆栈和内核进行很多调整，这将有所帮助。
我已经得到了10GB，只有适量的连接，它处理的要求就好了。
我将首先关注索引，然后让服务器pipe理员查看您的操作系统，如果所有这些都无助于实现主/从configuration。
总的来说，这是一个非常微妙的问题，并不是微不足道的。 我鼓励你阅读mysqlperformanceblog.com和高性能MySQL 。 我真的觉得这个没有一般的答案。
我正在开发一个拥有几乎1TB数据的MySQL数据库的项目。 RAM是最重要的可扩展性因素。 如果表的索引适合内存，并且查询得到高度优化，则可以使用平均机器来处理合理数量的请求。
logging的数量很重要，这取决于你的表格的样子。 拥有大量的varchar字段或只有一两个整数或长整数是有区别的。
数据库的物理大小也很重要：例如，考虑备份。 根据你的引擎，你的物理数据库文件增长，但不要缩小，例如与innodb。 所以删除大量的行，并不会缩小你的物理文件。
这个问题有很多，在许多情况下，魔鬼是在细节。
数据库大小确实很重要 。 如果您拥有多于一百万条logging的表格超过一个，那么性能的确会降低。 logging的数量当然会影响性能： 对于大型表，MySQL可能会很慢 。 如果命中一百万条logging，如果索引设置不正确（例如，没有在“WHERE语句”或“联合条件”中的字段的索引），将会出现性能问题。 如果您打开了1000万条logging，即使您的所有索引都是正确的，也会出现性能问题。 硬件升级 – 增加更多的内存和更多的处理器能力，尤其是内存 – 往往通过再次提高性能，至less在一定程度上帮助减less最严重的问题。 例如，对于Basecamp数据库服务器， 37个信号从32GB RAM变成128GB RAM 。
我将首先关注你的索引，而不是让服务器pipe理员看看你的操作系统，如果所有这些都无济于事，那么可能是主/从configuration的时候了。
确实如此。 另一个通常可行的方法是减less重复使用的数据量。 如果您有“旧数据”和“新数据”，并且有99％的查询使用新数据，只需将所有旧数据移动到另一个表 – 不要看它;）
– >看看分区 。
2GB和大约15M的logging是一个非常小的数据库 – 我已经运行在奔腾III（！）更大的一切，一切仍然运行得非常快..如果你的速度慢是一个数据库/应用程序devise问题，而不是一个MySQL一。
谈论“数据库性能”是毫无意义的，“查询性能”在这里是一个更好的术语。 答案是：它依赖于查询，操作的数据，索引，硬件等。您可以了解要扫描多less行以及EXPLAIN语法将使用哪些索引。
2GB并不算是一个“大”的数据库 – 它更像是一个中等大小的数据库。
我曾经被要求查看一个“停止工作”的mysql。 我发现数据库文件位于安装有NFS2的Network Appliance Filer上，文件大小最大为2GB。 当然，已经停止接受交易的表格在磁盘上恰好是2GB。 但是关于性能曲线，我被告知，它像一个冠军，直到它根本不工作！ 这个经验总是为我提供一个很好的提示，总是有一个你自然怀疑的维度。
要考虑的一点也是系统和日常数据的目的。
例如，对于具有GPS监控汽车的系统而言，与前几个月来自汽车位置的查询数据不相关。
因此可以将数据传递给其他历史表进行可能的咨询，并减less日常查询的执行时间。
还要注意复杂的联接。 除交易量外，交易复杂性可能是一个很大的因素。
重构大量查询有时会提高性能。
如果数据库devise不当，性能可能会降低到几千行。
如果你有适当的索引，使用适当的引擎（不要使用MyISAM，在多个DML的预期），使用分区，根据使用分配正确的内存，当然有良好的服务器configuration，MySQL甚至可以处理数据TB！
总是有方法来提高数据库的性能。
目前，我正在pipe理一个已经增长到160 GB的Amazon云基础设施上的MySQL数据库。 查询性能很好。 什么变成了噩梦是备份，恢复，增加奴隶，或其他任何处理整个数据集，甚至在大型表上的DDL。 获取转储文件的干净导入已成为问题。 为了使过程稳定到足以实现自动化，需要做出各种select来优先考虑稳定性而不是性能。 如果我们不得不使用SQL备份从灾难中恢复，那么我们将会停下来好几天。
水平扩展SQL也是非常痛苦的，并且在大多数情况下，导致以您select首先将数据放入SQL中时可能不想要的方式使用它。 碎片，读取奴隶，多主人等，他们都是真正的低劣的解决scheme，增加复杂性，你所做的一切与数据库，而不是其中之一解决问题; 只是以某种方式减轻它。 我强烈build议你在开始接近一个大小的数据集时，把你的一些数据从MySQL（或者任何SQL）中移出来，这些数据集会成为一个问题。
这取决于你的查询和validation。
例如，我使用了一张10万个药物的表格，这个药物列表中有一个通用名称，每个药物的表格中有15个以上的字符。我提出了一个查询来比较两个表格之间药物的通用名称。更多的时间运行。同样，如果您使用药物索引比较药物，使用id列（如上所述），只需要几秒钟。
数据库大小以字节和表格的行数来衡量。 你会注意到一个轻量级数据库和一个填充的blob之间巨大的性能差异。 一旦我的应用程序卡住了，因为我把二进制图像放在字段中，而不是将图像保存在磁盘上的文件中，而只把文件名放在数据库中。 另一方面，迭代大量的行并不是免费的。
