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

Question

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

Answer 1

"大"就像"聪明" - 它是相对的.1000万行是一个很好的大小,但表是否很大取决于许多因素:

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

搜索时间不一定由大小本身驱动,而是由您的索引策略的有效性以及您为搜索运行的查询类型.如果你有这样的事情:

WHERE description LIKE '%foo%'

那么正常的指数对你没有任何帮助,你应该开始担心.您可以考虑使用全文搜索这样的案例.

具有单个INT列的表中的1000万行(例如,Numbers表)什么都不是.1000万行产品具有长描述,XML,地理数据,图像等等.

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

Answer 2

在db设计中,large不是一个有用的概念.

性能取决于很多因素,但标签large不是其中之一.相反,关注自己:

• 硬件
• OS和db配置
• 架构设计
• 索引
• 查询优化
• 最重要的是,在具有等量数据和同时使用的等效硬件上进行自我测试

只有这样,您才会得到与您相关的答案.除此之外,应用程序设计也是一个重要因素.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进行认真的工作).

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

但是,如果您想减小表格大小:

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

摘要:

这比我预期的要长,所以总结一下:

1. 大的是相对的,但您必须考虑列大小以及行数.
2. 表大小肯定会影响性能,但很多其他因素会对它产生影响,因此我不会先看到第二个甚至第二个.
3. 如果必须减小表大小,基本上除去不需要的数据,并将其他数据重新分配到其他地方.但是你必须聪明地知道如何或你可以弊大于利.