SQL Server 中非常大的表

我们有一个非常大的表（> 77M 记录并且还在不断增长）在 SQL Server 2005 64 位标准版上运行，并且我们发现了一些性能问题。每天添加多达十万条记录。

有谁知道SQL Server标准版可以处理的记录数量是否有限制？应该考虑转向企业版还是有一些我们可以使用的技巧？

附加信息：

所讨论的表非常扁平（14 列），有一个包含 6 个字段的聚集索引，还有两个针对单个字段的索引。

我们使用一个问题查询中的选择中的 3 个字段添加了第四个索引，并且在估计性能方面没有看到任何差异（该查询是必须在非工作时间运行的流程的一部分，因此我们没有指标然而）。这些字段是聚集索引的一部分。

同意上面 Marc 和 Unkown 的观点...聚集索引中的 6 个索引太多了，尤其是在只有 14 列的表上。你不应该超过 3 或 4 个，如果是的话，我会说 1 或可能 2。你可能知道聚集索引是磁盘上的实际表，所以当插入一条记录时，数据库引擎必须对其进行排序并将其放在磁盘上已排序的组织位置中。非聚集索引则不然，它们支持查找“表”。我的 VLDB 根据下面的第一点布置在磁盘上（聚集索引）。

1. 将聚集索引减少到 1 或 2。最好的字段选择是 IDENTITY (INT)（如果有）、日期字段（其中的字段将添加到数据库）或其他一些自然排序的字段。您的数据如何添加到数据库中。关键是您试图将这些数据保留在表的底部......或者将其以您将读取记录的最佳方式（90%+）放置在磁盘上。这样就不会发生重组，或者只需要一次点击即可将数据放在正确的位置以实现最佳读取。请务必将删除的字段放入非聚集索引中，这样就不会失去查找功效。我从来没有在 VLDB 上放置超过 4 个字段。如果您有经常更新的字段并且它们包含在聚集索引中，哎呀，这将重新组织磁盘上的记录并导致代价高昂的碎片。
2. 检查索引上的填充因子。填充因子数字 (100) 越大，数据页和索引页就越满。关于您拥有的记录数以及要插入的记录数，您将更改非聚集索引的填充因子#（+或-），以在插入记录时留出填充空间。如果将聚集索引更改为顺序数据字段，那么这对于聚集索引来说就不那么重要了。根据经验（IMO），高写入的填充因子为 60-70，中等写入的填充因子为 70-90，高读取/低写入的填充因子为 90-100。将填充因子降低到 70 意味着页面上每 100 条记录写入 70 条记录，这将为新记录或重组记录留下 30 条记录的可用空间。占用更多空间，但它肯定比每晚必须进行碎片整理（参见下面的 4）
3. 确保统计信息存在于表中。如果你想使用“sp_createstats 'indexonly'”扫描数据库来创建统计信息，那么SQL Server将在引擎累积的所有索引上创建所有统计信息作为需要统计信息。但不要忽略“indexonly”属性，否则您将为每个字段添加统计信息，这样就不好了。
4. 使用 DBCC SHOWCONTIG 检查表/索引，以查看哪些索引碎片最多。我不会在这里详细介绍，只需知道您需要这样做即可。然后根据该信息，根据索引正在经历的变化以及变化的速度（随着时间的推移）向上或向下更改填充因子。
5. 设置一个作业计划，对各个索引执行联机 (DBCC INDEXDEFRAG) 或脱机 (DBCC DBREINDEX) 操作以对其进行碎片整理。警告：如果不在维护期间，请勿在这么大的表上执行 DBCC DBREINDEX，因为它会导致应用程序崩溃……尤其是在聚集索引上。你已被警告过。测试并测试这部分。
6. 使用执行计划查看存在哪些 SCANS 和 FAT PIPES 并调整索引，然后整理碎片并重写存储过程以消除这些热点。如果您在执行计划中看到红色对象，那是因为该字段没有统计信息。那很糟。这一步更像是“艺术而不是科学”。
7. 在非高峰时间，运行 UPDATE STATISTICS WITH FULLSCAN 为查询引擎提供尽可能多的有关数据分布的信息。否则，在工作日晚上或更频繁地在表上执行标准 UPDATE STATISTICS（使用标准 10% 扫描），只要您认为符合您的观察结果，即可确保引擎拥有有关数据分布的更多信息，以便高效地检索数据。

抱歉，这篇文章太长了，但这非常重要。我在这里只向您提供最少的信息，但会有很大帮助。这些要点所使用的策略涉及一些直觉和观察，需要您的时间和测试。

无需转到企业版。我这样做是为了获得前面提到的分区功能。但我特别是为了拥有更好的多线程功能，包括搜索、在线碎片整理和维护……在企业版中，它对 VLDB 来说更好、更友好。标准版也不处理对在线数据库执行 DBCC INDEXDEFRAG。