MySQL数据库在什么时候开始失去性能?
物理数据库大小重要吗? 记录的数量重要吗? 性能下降是线性的还是指数级的?
我有一个我相信是一个大的数据库,大约有1500万条记录,占用了近2GB。基于这些数字,我是否有任何动机清理数据,或者我是否可以允许它继续扩展几年?
MySQL数据库在什么时候开始失去性能?
物理数据库大小重要吗? 记录的数量重要吗? 性能下降是线性的还是指数级的?
我有一个我相信是一个大的数据库,大约有1500万条记录,占用了近2GB。基于这些数字,我是否有任何动机清理数据,或者我是否可以允许它继续扩展几年?
当前回答
这取决于您的查询和验证。
例如,我处理过一个包含10万种药物的表格,表格中每个药物都有一个超过15个字符的列通用名。我输入了一个查询来比较两个表格之间药物的通用名。查询需要更多的时间来运行。同样,如果使用药物索引,使用id列(如上所述)比较药物,只需要几秒钟。
其他回答
谈论“数据库性能”有点毫无意义,“查询性能”在这里是一个更好的术语。答案是:这取决于查询,它所操作的数据,索引,硬件等。您可以了解将要扫描多少行,以及使用EXPLAIN语法将使用哪些索引。
2GB并不算真正的“大”数据库——它更像是一个中等大小的数据库。
我将首先关注您的索引,然后让服务器管理员查看您的操作系统,如果所有这些都没有帮助,可能是时候进行主/从配置了。
这是真的。另一个通常有效的方法是减少重复处理的数据量。如果你有“旧数据”和“新数据”,并且99%的查询都使用新数据,只需将所有旧数据移动到另一个表中-并且不要查看它;)
->看看分区。
数据库大小确实与字节数和表的行数有关。您将注意到light数据库和blob填充数据库之间的巨大性能差异。有一次我的应用程序卡住了,因为我把二进制图像放在字段中,而不是把图像保存在磁盘上的文件中,只把文件名放在数据库中。另一方面,迭代大量的行并不是免费的。
不,这并不重要。MySQL的速度大约是每秒700万行。所以你可以把它放大一点
物理数据库大小无关紧要。记录的数量并不重要。
In my experience the biggest problem that you are going to run in to is not size, but the number of queries you can handle at a time. Most likely you are going to have to move to a master/slave configuration so that the read queries can run against the slaves and the write queries run against the master. However if you are not ready for this yet, you can always tweak your indexes for the queries you are running to speed up the response times. Also there is a lot of tweaking you can do to the network stack and kernel in Linux that will help.
我的内存达到了10GB,只有中等数量的连接,它处理请求还不错。
我将首先关注您的索引,然后让服务器管理员查看您的操作系统,如果所有这些都没有帮助,那么可能是时候实现主/从配置了。