我正在为实时AJAX Web应用程序设计我的数据库功能和性能，我目前没有资源来添加数据库服务器冗余或负载平衡。
不幸的是，我的数据库中有一个表可能最终存储数亿行，并且需要快速读写以防止滞后于Web界面。
此表中的大多数（如果不是全部）列都是单独编制索引的，我很想知道在大型表上运行查询时是否还有其他方法可以减轻服务器的负担。但是，在单个非集群SQL服务器开始阻塞之前，最终是否存在表的大小（行或 GB）上限？
我的数据库只有十几个表，可能有十几个关键关系。我的表中没有一个列有超过8个列，并且这些表中只有一个或两个最终会存储大量行。希望我的数据库的简单性能够弥补这些表格中的大量数据......
答案 0 :(得分：4)
唯一的限制是主键的大小。它是INT还是BIGINT？
SQL会愉快地存储数据而不会出现问题。但是，拥有1亿行，您最好对数据进行分区。有很多好文章，例如article。
使用分区，每个分区可以同时运行1个线程，以便在不进行分区的情况下进行并行查询。
答案 1 :(得分：4)
行严格受限于您可用的磁盘空间量。我们有SQL Server，其中包含数亿行数据。当然，这些服务器相当大。
为了保持网络界面的流畅，您需要考虑如何访问该数据。
一个例子是远离任何需要处理大量数据的聚合查询。像SUM（）这样的东西可能是一个杀手，取决于它试图处理多少数据。在这些情况下，您最好提前计算任何摘要或分组数据，并让您的网站查询这些分析表。
接下来，您需要对数据进行分区。跨不同驱动器阵列拆分这些分区。当SQL需要转到磁盘时，它可以更容易地并行化读取。 （@Simon谈到了这一点）。
基本上，问题归结为您一次需要访问多少数据。无论您在磁盘上拥有多少数据，这都是主要问题。如果驱动器很慢并且数据库服务器中的可用RAM量不足以在内存中保留足够的数据库，即使是小型数据库也会被阻塞。
通常对于像这样的系统来说，大量数据基本上是惰性的，这意味着它很少被访问。例如，PO系统可能会保留所有已创建发票的历史记录，但它们实际上只处理任何活动发票。
如果您的系统有类似的要求，那么您可能有一个用于活动记录的表，只需将它们存档到另一个表中，作为夜间过程的一部分。您甚至可以将月平均值（例如）重新计算为该档案的一部分。
只是一些想法。
答案 2 :(得分：1)
我的直觉告诉我你可能会好起来，但你必须要处理表现。它将取决于从查询中检索结果的可接受时间。
对于包含“数亿行”的表格，定期访问的数据百分比是多少？是一些数据，很少访问？有些用户访问所选数据而其他用户选择不同的数据吗？您可能会受益于数据分区。