还有一点需要考虑的是系统和数据在日常生活中的用途。

例如，对于一个用GPS监控汽车的系统来说，查询汽车前几个月的位置数据是不相关的。

因此，可以将数据传递给其他历史表，以便进行可能的查询，并减少日常查询的执行次数。

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.

The database size does matter. If you have more than one table with more than a million records, then performance starts indeed to degrade. The number of records does of course affect the performance: MySQL can be slow with large tables. If you hit one million records you will get performance problems if the indices are not set right (for example no indices for fields in "WHERE statements" or "ON conditions" in joins). If you hit 10 million records, you will start to get performance problems even if you have all your indices right. Hardware upgrades - adding more memory and more processor power, especially memory - often help to reduce the most severe problems by increasing the performance again, at least to a certain degree. For example 37 signals went from 32 GB RAM to 128GB of RAM for the Basecamp database server.

还有一点需要考虑的是系统和数据在日常生活中的用途。

例如，对于一个用GPS监控汽车的系统来说，查询汽车前几个月的位置数据是不相关的。

因此，可以将数据传递给其他历史表，以便进行可能的查询，并减少日常查询的执行次数。

还要注意复杂连接。除了交易量之外，交易复杂性也是一个很大的因素。

重构繁重的查询有时会大大提高性能。

如果数据库设计不当，性能可能会在几千行中下降。

如果你有合适的索引，使用合适的引擎(不要使用MyISAM，因为需要多个dml)，使用分区，根据使用情况分配正确的内存，当然还有良好的服务器配置，MySQL可以处理tb级的数据!

总有办法提高数据库性能。