在 SQL SERVER 中索引大表答案

【问题标题】：indexing large table in SQL SERVER在 SQL SERVER 中索引大表
【发布时间】：2010-09-22 00:55:08
【问题描述】：

我有一张大表（超过 1000 万条记录）。该表在应用程序中大量用于搜索。所以，我不得不在表上创建索引。但是，当在表中插入或更新记录时，我会遇到性能缓慢的问题。这很可能是因为重新计算了索引。

有没有办法改善这个。

提前致谢

【问题讨论】：

【解决方案1】：

您可以尝试通过减少索引的填充因子来减少页面拆分的数量（在您的索引中）。默认情况下，填充因子为 0（与 100% 相同）。因此，当您重建索引时，页面会被完全填满。这对于未修改的表（插入/更新/删除）非常有用。但是，当数据被修改时，索引需要改变。填充因子为 0 时，您一定会得到分页。

通过修改填充因子，您应该在插入和更新方面获得更好的性能，因为页面不会总是被拆分。我建议您使用 Fill Factor = 90 重建索引。这将使 10% 的页面留空，这将导致更少的页面拆分，从而减少 I/O。 90 可能不是使用的最佳值，因此这里可能涉及一些“反复试验”。

通过使用不同的填充因子值，您的选择查询可能会稍微变慢，但如果填充因子为 90%，您可能不会注意到太多。

【讨论】：

【解决方案2】：

您可以选择多种解决方案

a) 你可以对表进行分区

b) 考虑在非高峰时间（如晚上）批量执行更新

c) 由于工程是权衡取舍的平衡行为，因此您必须选择哪个更重要（选择或更新/插入/删除）以及哪个操作更重要。假设您不需要“插入”的实时结果，您可以使用 Sql server 服务代理进行这些操作以异步执行“不太重要”的操作

谢谢 -RVZ

【讨论】：

【解决方案3】：

我们需要查看您的索引，但很可能是的。

要记住的一些事情是，您不希望只在每一列上放置一个索引，而且您通常不希望每个索引只有一列。

最好的办法是，如果您可以记录一些实际搜索，跟踪用户实际搜索的内容，并针对这些特定类型的搜索创建索引。

【讨论】：

【解决方案4】：

这是一个经典的工程权衡...您可以使铲子更轻或更坚固，但不能两者兼而有之...（直到材料科学取得突破。）

更多的索引意味着更多的 DML 维护，意味着更快的查询。

更少的索引意味着更少的 DML 维护，意味着更慢的查询。

您的某些索引可能是多余的并且可以合并。

除了 Joel 所写的内容之外，您还需要为 DML 定义 SLA。它变慢了可以吗？您注意到它变慢了，但这与您实现的查询改进相比真的很重要吗... IOW，有这么弱的轻型铲子可以吗？

【讨论】：

【解决方案5】：

如果您有一个不在标识数字字段上的聚集索引，重新排列页面可能会减慢您的速度。如果是这种情况，请查看是否可以通过将其设为非聚集索引来提高速度（比无索引快，但往往比聚集索引慢一点，因此您的选择可能会减慢，但插入会提高）

我发现用户更愿意容忍稍慢的插入或更新到较慢的选择。这是一条一般规则，但如果它变得非常慢（或更糟糕的超时），那么没有人可以处理得很好。

【讨论】：