Question

我有一张包含1000万条记录的表格。这被认为是很多记录吗？我应该担心搜索时间吗？如果没有，它会继续增长，那么被认为是一张大桌子？表格大小对搜索时间有多大影响，我可以做些什么来改善这些问题，最好是在它们成为问题之前？

Answer 1

＆＃34;大＆＃34;就像＆＃34;聪明＆＃34; - 它的亲戚。 1000万行是一个很好的大小，但表是否很大取决于许多因素：

有多少列以及它们的数据类型是什么？
有多少索引？
表的实际大小是多少（例如，您可以从sys.dm_db_partition_stats获得的页数* 8kb）？
针对它运行什么类型的查询？
是内存中保存的单个索引，还是大多数查询都受益于聚簇索引扫描（基本上，整个表需要在内存中）？
机器上有多少内存？
你认为什么？

搜索时间不一定是由尺寸本身驱动，而是由您的索引策略的有效性以及您为搜索运行的查询类型。如果您有以下内容：

WHERE description LIKE '%foo%'

那么正常的指数对你没有任何帮助，你应该开始担心。您可以考虑对此类案例进行全文搜索。

具有单个INT列的表中的1000万行（例如Numbers表）不算什么。 1000万行具有长描述，XML，地理数据，图像等的产品是另一种产品。

有一个原因是SQL Server的最大容量规范没有记录表中行数的上限。

Answer 2

large 在数据库设计中不是一个有用的概念。

性能取决于很多因素，但标签large不是其中之一。相反，请关注自己：

硬件
操作系统和数据库配置
架构设计
索引
查询优化
最重要的是，在具有等量数据和同时使用的等效硬件上进行自我测试

只有这样，您才会得到与您相关的答案。除此之外，应用程序设计也是一个重要因素。 N + 1查询和缓存会对感知（和实际）性能产生巨大影响。

Answer 3

正如亚伦所说，这是相对的。但也许我可以详细说明一些。

首先，一个主要因素是列的大小。如果你有一个只有1000万个整数的表（并且有理由你可能想要这样的东西，请看Tally Tables。）那么它根本就不大。另一方面，只有一百行的非规范化表可能占用大量空间并且如果每行包含一个id字段，其中整数充当主键，后跟varchar（max）和html，则会产生大量性能问题然后是一系列varbinary（max）列，其中包含该html使用的jpgs。

因此，要掌握表的大小，您需要查看行数和每行的大小。对于可能更有用的大小的一个度量标准是查看它占用的空间。（假设这比SQL Server 2000晚，您可以右键单击SSMS中的表，转到属性，然后转到存储页面。）

当然，仍然很难说何时会开始影响性能。一旦表格太大而无法放入RAM内部，您肯定会注意到性能的变化，但是这种情况可能会在大小合适的数据集中频繁发生，特别是如果您选择部分非规范化并且不是引起关注的原因。索引太大而无法容纳在RAM内部会导致更大的性能问题，并且可能会导致进行评估。但它不一定是一个问题，特别是如果它是一个覆盖索引的某些查询，你正在使用RAM约束环境（RAM约束意味着也是相对的，但对于一个粗略的经验法则，我会尝试甚至在桌面上至少要使用8 GB，这对于使用SQL Server的工作非常重要。

现在，表格大小当然可以成为搜索速度的一个因素，并且有办法处理它。但在我谈到这些之前，请允许我指出，这通常是我在性能方面看到的较小因素之一。我最近写了一篇关于此事的文章here。在考虑表大小之前，我会考虑确保查询已经优化，并且索引是有意义的。我甚至会考虑增加内存并获得更快的硬盘驱动器（SSDs如果你能负担得起一个足够大的硬盘用于你的目的），那么在担心桌面尺寸之前。

但是，如果你想减少表格大小：

正常化。这实际上可能会对性能产生一些重大缺陷，但它可以具有一些性能优势，并且具有很大的数据一致性优势以及存储优势。
考虑您的数据类型。如果您需要NVarchar，则需要NVarchar。但是如果varchar会起作用，那么它将占用更少的空间。与int vs bigint相同。
分区。再次，做错了这会降低性能而不是改进性能，但做得正确它可以帮助提高性能。做正确的做法可能有点棘手，所以谨慎行事。
将旧的，不必要的数据移至档案仓库并移出主系统。当然，这取决于正确定义不必要的数据。

<强>要点：

这比我预期的要长，所以总结一下：

大的是相对的，但您必须考虑列大小以及行数。
表格大小肯定会影响表现，但很多其他因素对它的影响更大，所以我不会先看那里甚至第二。
如果必须减小表大小，基本上除去不需要的数据，并将其他数据重新分配到其他地方。但是你必须聪明地知道如何或者你可以弊大于利。

Answer 4

一切都是相对的......

我曾经是一家设计，构建和托管营销数据库的公司的DBA，并且有数十亿行的数据库并不罕见。所以我们的小型数据库被认为很小。

此外，任何架构中往往会有一些表具有大量数据（例如事务），而其他表可能是较小的查找表。

我所得到的是，没有任何一个表变得“大”。

如果您有一张大表，那么这肯定是优化的候选者。我说“可能”，因为表变得非常大但很少用于查询（例如历史表）是完全合理的。

Answer 5

同样关于“大”的海报取决于您的数据是什么，您想要做什么样的查询，您的硬件是什么，以及您对原因搜索时间的定义是什么。

但是这里有一种定义“大”的方法：“大”表是超出主机可以分配给SQL Server的实际内存量的表。 SQL Server完全能够处理大小超过物理内存的表，但是只要查询需要对这样的表进行表扫描（即，读取每个记录），就会遭到破坏。理想情况下，您希望将整个表保留在内存中;如果那是不可能的，你至少要在内存中保留必要的索引。如果你有一个支持你的查询的索引，并且你可以将该索引保存在RAM中，那么性能仍然可以很好地扩展。

如果您作为设计人员并不明白您的聚集索引（数据的物理排列）和非聚集索引（本质上是指向聚簇索引的指针）应该是什么，SQL Server会提供非常好的分析工具，帮助您以适当的方式为工作负载定义索引。

最后，考虑向问题投掷硬件。 SQL Server性能几乎总是受内存限制而不是cpu绑定，所以不要购买快速的8核机器并使用4 GB的物理内存来削弱它。如果您需要100 GB数据库中可靠的低延迟，请考虑将其托管在64 GB甚至128 GB的ram机器上。

Answer 6

如果您在任何表格中有1000万条记录，现在是时候研究一下了。如果它与任何类型的审核日志相关，则可以正常，但除此之外您必须小心性能。

什么被认为是SQL Server中的“大”表？

6 个答案: