sql-server - 在 SQL SERVER 中索引大表

Question

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

有没有办法改善这一点。

提前致谢

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

您可以选择多种解决方案

a）您可以对表进行分区

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

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

http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx

谢谢-RVZ

Answer 4

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

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

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

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

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

Answer 5

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

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