25

我有一张表，里面有 1000 万条记录。这算不算很多记录？我应该担心搜索时间吗？如果不是，它会一直增长，那么什么才算大表呢？表大小对搜索时间的影响有多大，我能做些什么来改善这些问题，最好是在它们成为问题之前？

4

6 回答 6

36

“大”就像“聪明”——它是相对的。1000 万行是一个不错的大小，但表是否很大取决于许多因素：

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

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

WHERE description LIKE '%foo%'

那么一个正常的指数对你没有任何帮助，你应该开始担心了。对于这种情况，您可以考虑全文搜索。

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

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

于 2012-09-19T15:48:07.643 回答
7

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

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

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

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

于 2012-09-19T15:51:28.043 回答
7

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

首先，一个主要因素是列有多大。如果你有一个只有 1000 万个整数的表（并且有一些原因你可能想要这样的东西，看看Tally Tables。）那么它根本就不大。另一方面，如果每行包含一个 id 字段，其中一个整数作为主键，然后是一个带有 html 的 varchar(max)然后是一系列 varbinary(max) 列，其中包含该 html 使用的 jpgs。

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

当然，仍然很难说什么时候会开始影响性能。一旦表变得太大而无法容纳在 RAM 中，您肯定会注意到性能的变化，但是对于大小合适的数据集，这种情况经常发生，特别是如果您选择部分非规范化并且不需要担心。拥有太大而无法放入 RAM 的索引可能会导致更大的性能问题，并且可能需要进行评估。但这不一定是问题，特别是如果它是某些查询的覆盖索引并且您正在使用 RAM 受限的环境（RAM 受限的含义也是相对的，但是对于粗略的经验法则，我会尝试即使是要使用 SQL Server 进行认真工作的桌面，也至少要放置 8 GB）。

现在，表大小当然可以成为搜索速度的一个因素，并且有一些方法可以处理它。但在我谈论这些之前，让我指出，这通常是我在性能方面会考虑的较小因素之一。我最近在这里写了一篇关于这个的文章。在考虑表大小之前，我会确保查询已经过优化，并且索引是有意义的。在担心表大小之前，我什至会考虑增加 RAM 并获得更快的硬盘驱动器（如果您能负担得起足够大的硬盘驱动器， SSD会有所作为）。

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

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

概括：

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

  1. 大是相对的，但您必须考虑列大小以及行数。
  2. 表大小肯定会影响性能，但还有很多其他因素会影响它，所以我不会先看，甚至不会看第二。
  3. 如果一定要减小表大小，基本上把不需要的数据去掉，把其他数据重新分配到其他地方。但是你必须聪明地知道如何或你可以做的弊大于利。
于 2012-09-19T16:16:34.537 回答
2

一切都是相对的...

我曾经是一家设计、构建和托管营销数据库的公司的 DBA，拥有数十亿行的数据库并不少见。因此，其他具有数百万行的数据库被认为是“小”的。

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

我要说的是，桌子不会变“大”。

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

于 2012-09-19T15:52:59.927 回答
0

与其他海报一样，关于“大”的程度取决于您的数据是什么，您想要执行什么样的查询，您的硬件是什么，以及您对原因搜索时间的定义是什么。

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

如果你作为设计者不清楚你的聚集索引（数据的物理排列）和非聚集索引（指向聚集索引的指针，本质上）应该是什么，SQL Server 带有非常好的分析工具，可以帮助你定义以适合您的工作负载的方式建立索引。

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

于 2012-09-19T16:46:30.343 回答
0

如果您在任何表中都有 1000 万条记录，那么现在是查看相同记录的时候了。如果它与任何类型的审核日志相关，则可以，但否则您必须注意性能。

于 2014-08-20T19:31:14.063 回答