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