MySQL数据库在什么时候开始失去性能?
物理数据库大小重要吗? 记录的数量重要吗? 性能下降是线性的还是指数级的?
我有一个我相信是一个大的数据库,大约有1500万条记录,占用了近2GB。基于这些数字,我是否有任何动机清理数据,或者我是否可以允许它继续扩展几年?
MySQL数据库在什么时候开始失去性能?
物理数据库大小重要吗? 记录的数量重要吗? 性能下降是线性的还是指数级的?
我有一个我相信是一个大的数据库,大约有1500万条记录,占用了近2GB。基于这些数字,我是否有任何动机清理数据,或者我是否可以允许它继续扩展几年?
当前回答
数据库大小确实与字节数和表的行数有关。您将注意到light数据库和blob填充数据库之间的巨大性能差异。有一次我的应用程序卡住了,因为我把二进制图像放在字段中,而不是把图像保存在磁盘上的文件中,只把文件名放在数据库中。另一方面,迭代大量的行并不是免费的。
其他回答
谈论“数据库性能”有点毫无意义,“查询性能”在这里是一个更好的术语。答案是:这取决于查询,它所操作的数据,索引,硬件等。您可以了解将要扫描多少行,以及使用EXPLAIN语法将使用哪些索引。
2GB并不算真正的“大”数据库——它更像是一个中等大小的数据库。
不,这并不重要。MySQL的速度大约是每秒700万行。所以你可以把它放大一点
总的来说,这是一个非常微妙的问题,无论如何都不是微不足道的。我建议你阅读mysqlperformanceblog.com和高性能MySQL。我真的认为这个问题没有普遍的答案。
我正在做一个项目,它有一个MySQL数据库,几乎有1TB的数据。最重要的可伸缩性因素是RAM。如果您的表的索引适合内存,并且您的查询得到了高度优化,那么您可以使用普通机器处理合理数量的请求。
记录的数量确实很重要,这取决于表的外观。有很多varchar字段和只有几个int或long类型是有区别的。
数据库的物理大小也很重要:例如,考虑备份。根据你的引擎,你的物理db文件会增长,但不会缩小,例如innodb。因此,删除大量的行,并不有助于缩小您的物理文件。
这个问题有很多,在很多情况下,细节决定成败。
还有一点需要考虑的是系统和数据在日常生活中的用途。
例如,对于一个用GPS监控汽车的系统来说,查询汽车前几个月的位置数据是不相关的。
因此,可以将数据传递给其他历史表,以便进行可能的查询,并减少日常查询的执行次数。
我将首先关注您的索引,然后让服务器管理员查看您的操作系统,如果所有这些都没有帮助,可能是时候进行主/从配置了。
这是真的。另一个通常有效的方法是减少重复处理的数据量。如果你有“旧数据”和“新数据”,并且99%的查询都使用新数据,只需将所有旧数据移动到另一个表中-并且不要查看它;)
->看看分区。