MySQL数据库在什么时候开始失去性能?
物理数据库大小重要吗? 记录的数量重要吗? 性能下降是线性的还是指数级的?
我有一个我相信是一个大的数据库,大约有1500万条记录,占用了近2GB。基于这些数字,我是否有任何动机清理数据,或者我是否可以允许它继续扩展几年?
MySQL数据库在什么时候开始失去性能?
物理数据库大小重要吗? 记录的数量重要吗? 性能下降是线性的还是指数级的?
我有一个我相信是一个大的数据库,大约有1500万条记录,占用了近2GB。基于这些数字,我是否有任何动机清理数据,或者我是否可以允许它继续扩展几年?
当前回答
谈论“数据库性能”有点毫无意义,“查询性能”在这里是一个更好的术语。答案是:这取决于查询,它所操作的数据,索引,硬件等。您可以了解将要扫描多少行,以及使用EXPLAIN语法将使用哪些索引。
2GB并不算真正的“大”数据库——它更像是一个中等大小的数据库。
其他回答
数据库大小确实与字节数和表的行数有关。您将注意到light数据库和blob填充数据库之间的巨大性能差异。有一次我的应用程序卡住了,因为我把二进制图像放在字段中,而不是把图像保存在磁盘上的文件中,只把文件名放在数据库中。另一方面,迭代大量的行并不是免费的。
2GB和约15M条记录是一个非常小的数据库-我在奔腾III上运行过更大的数据库(!),一切仍然运行得非常快。如果你的慢,那是数据库/应用程序设计的问题,而不是mysql的问题。
I once was called upon to look at a mysql that had "stopped working". I discovered that the DB files were residing on a Network Appliance filer mounted with NFS2 and with a maximum file size of 2GB. And sure enough, the table that had stopped accepting transactions was exactly 2GB on disk. But with regards to the performance curve I'm told that it was working like a champ right up until it didn't work at all! This experience always serves for me as a nice reminder that there're always dimensions above and below the one you naturally suspect.
还有一点需要考虑的是系统和数据在日常生活中的用途。
例如,对于一个用GPS监控汽车的系统来说,查询汽车前几个月的位置数据是不相关的。
因此,可以将数据传递给其他历史表,以便进行可能的查询,并减少日常查询的执行次数。
还要注意复杂连接。除了交易量之外,交易复杂性也是一个很大的因素。
重构繁重的查询有时会大大提高性能。