什么是Server中的“大”表？

Question

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

Answer 1

“大”就像“聪明”--是相对的。1,000万行是一个很好的大小，但是表是否很大取决于以下几个因素：

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

搜索时间不一定取决于大小本身，而是取决于索引策略的有效性和为搜索而运行的查询类型。如果你有这样的事情：

WHERE description LIKE '%foo%'

然后一个正常的指数不会对你有任何帮助，你应该开始担心了。你可以考虑全文搜索这样的案例。

一个表中有一个INT列(例如数字表)的1千万行是没有意义的。一千万行包含长描述、XML、地理数据、图像等的产品是另一回事。

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

Answer 2

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

性能是由许多因素决定的，但是标签large不是其中之一。相反，要关注：

• 硬件
• OS和db配置
• 图式设计
• 标引
• 查询优化
• 最重要的是，自己在等效的硬件上进行测试，该硬件具有等效的数据量，并且处于并发使用状态。

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

Answer 3

就像亚伦说的，这是相对的。但也许我可以详细说明一下。

首先，一个主要因素是列有多大。如果您有一个只有1,000万个整数的表(而且您可能只是想要这样的东西，请看理货表)。那么它一点也不大。另一方面，一个仅为100行的非规范化表可能占用大量的空间，如果每行包含一个id字段，其中一个整数作为主键，然后是html的varchar(max)，然后是包含该html使用的jpgs的var二进制(Max)列，则可能会占用大量的性能问题。

因此，要获得表大小的句柄，需要同时查看行数和每一行的大小。衡量尺寸的一个指标可能会更有用，那就是看看它占用的空间。(假设这比Server 2000晚，您可以右键单击SSMS中的表，转到属性，然后转到存储页。)

当然，很难说这会在什么时候开始影响性能。一旦表变得太大，无法容纳RAM中，您肯定会注意到性能上的变化，但对于大小适中的数据集，这种情况可能经常发生，特别是如果您选择部分去角色化，并且不需要担心。如果索引太大，无法容纳在RAM中，则可能会引起更大的性能问题，而这可能是评估的原因。但这并不一定是一个问题，特别是如果它是某个查询的覆盖索引，并且您使用的是RAM受限环境( RAM受限的意思也是相对的，但是对于一个粗略的经验规则，我会尝试至少在一个桌面上使用SQL Server来完成8GB的任务)。

现在，表的大小当然可以成为搜索速度的一个因素，并且有一些方法来处理它。不过，在我谈及这些问题之前，请允许我指出，这通常是我在表现方面较小的因素之一。我最近写了一篇关于这里的文章。在考虑表大小之前，我希望确保查询是优化的，索引是有意义的。我甚至会考虑增加内存和获得更快的硬盘(如果您能负担得起足够大的内存，那么SSD就会有所不同)，然后再考虑表的大小。

但是，如果您想缩小表的大小：

• 正常化。实际上，这在性能上可能有一些很大的缺点，但是它也有一些性能优势，而且它具有数据一致性和存储优势。
• 考虑一下您的数据类型。如果你需要NVarchar，你就需要NVarchar。但是如果varchar能工作，那么它就会消耗更少的空间。int对bigint也是如此。
• 隔断。同样，如果做错了--这会降低性能而不是提高性能，但是正确的做法可以帮助提高性能。做正确的事情可能有些棘手，所以要谨慎行事。
• 将旧的、不必要的数据移到档案仓库，然后离开主系统。当然，这取决于如何正确定义不必要的数据。

摘要：

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

1. 较大的是相对的，但是您必须考虑列的大小和行数。
2. 表的大小肯定会影响性能，但是很多其他因素对它的影响更大，所以我不会先看，甚至不会看第二。
3. 如果必须缩小表的大小，基本上可以去掉不需要的数据，并将其他数据重新分配到其他地方。但是你必须在如何或你能做更多的伤害而不是好处的问题上变得聪明。