我正在为将拥有用户的应用程序构建数据库方案，并且每个用户在关系表中将有许多行，例如“favorites”。 每个用户可能有数千个收藏夹，并且可能有数千个注册用户（随着时间的推移）。
鉴于用户永远不会被删除，因为这会使其他实体孤立，或者将它们删除（这是不可取的），因此这些表将永远增长，我想知道结果表是否可以太大了（例如：1kk行），我应该担心这个并做一些事情，比如将旧的和非活动用户标记为已删除，并删除仅影响它们的关系（例如收藏夹和其他偏好）。
这是要走的路吗？或者mysql可以轻松处理表中的1kk行？有已知的限制吗？或者它完全取决于硬件？
答案 0 :(得分：23)
我同意klennepette和Brian的观点 - 并提出几点警告。
如果您的数据本质上是关系型的，并且受到与SQL兼容的查询的影响，那么您应该能够扩展到数亿条记录，而无需特殊的硬件要求。
您需要投资索引，查询调优，并为了速度而偶尔牺牲关系模型。在设计表时，您至少应该对性能表示赞同 - 例如，将整数更改为键的字符串。
但是，如果您有以文档为中心的要求，需要自由文本搜索，或者有很多层次关系，您可能需要再次查看。
如果您需要ACID交易，您可能会比不关心交易时更早遇到可扩展性问题（尽管这在实践中仍然不太可能影响您）;如果您有长期运行或复杂的事务，那么您的可伸缩性会迅速降低。
我建议从头开始构建项目，并考虑可扩展性要求。我过去所做的是建立一个填充了数百万条记录的测试环境（我使用过DBMonster，但不确定是否仍然存在），并使用负载测试工具定期测试正在进行的代码JMeter的。
答案 1 :(得分：7)
这是一个示例，演示了使用精心设计/规范化的innodb模式可以获得什么，该模式利用了innodb的集群主键索引（myisam不提供）。该示例基于具有线程的论坛，在负载下具有5亿行和0.02秒的查询运行时。
答案 2 :(得分：6)
数百万行很好，数千万行很好 - 前提是你有一个相当不错的服务器，即几Gbs的RAM，足够的磁盘空间。您将需要了解快速检索的索引，但就MySQL能够处理它而言，没问题。
答案 3 :(得分：4)
它主要依赖于硬件，但据说MySQL可以很好地扩展。 我不会过分担心表格大小，如果它确实成为问题，你可以随时使用partitioning来缓解压力。