我有一张大桌子（超过一千万条记录）。此表大量用于在应用程序中搜索。所以，我不得不在桌面上创建索引。但是，在表中插入或更新记录时，我的性能会降低。这很可能是因为重新计算了索引。
有没有办法改善这一点。
提前致谢
答案 0 :(得分：9)
您可以尝试通过减少索引的填充因子来减少页面拆分的数量（在索引中）。默认情况下，填充因子为0（与100％相同）。因此，当您重建索引时，页面将完全填满。这适用于未修改的表（插入/更新/删除）。但是，在修改数据时，索引需要更改。如果填充因子为0，则可以保证页面拆分。
通过修改填充因子，您应该在插入和更新时获得更好的性能，因为页面不总是必须拆分。我建议您使用填充因子= 90重建索引。这将使页面的10％空，这将导致页面拆分更少，因此I / O更少。 90可能不是最佳使用价值，因此这里可能涉及一些“试验和错误”。
通过使用不同的填充因子值，您的选择查询可能会稍微变慢，但填充因子为90％时，您可能不会注意到太多。
答案 1 :(得分：2)
我们需要查看您的索引，但可能是。
要记住的一些事情是，您不希望仅在每个列上放置索引，并且通常不希望每个索引只有一列。
最好的办法是，您可以记录一些实际搜索，跟踪用户实际搜索的内容，并创建针对这些特定类型搜索的索引。
答案 2 :(得分：2)
您可以选择多种解决方案
a）您可以对表格进行分区
b）考虑在非高峰时段（如夜间）批量执行更新
c）由于工程是权衡的平衡行为，你必须选择哪个更重要（选择或更新/插入/删除）以及哪个操作更重要。假设您不需要实时获得“插入”的结果，您可以使用Sql server服务代理来执行这些操作，以异步方式执行“不太重要”的操作http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx
由于 -RVZ
答案 3 :(得分：0)
这是一个经典的工程权衡...你可以使铲子更轻或更强，从不两者......（直到材料科学的突破。）
更多索引意味着更多DML维护，意味着更快的查询。
较少的索引意味着DML维护较少，意味着查询速度较慢。
有些索引可能是多余的，可以合并。
除了Joel写的内容之外，您还需要为DML定义SLA。可以慢一些，你注意到它放慢了速度，但它确实比你已经实现的查询改进真的很重要...... IOW，是否可以使用轻型铲子？
答案 4 :(得分：0)
如果您的聚簇索引不在标识数字字段中，重新排列页面可能会降低您的速度。如果是这种情况，你可以看看你是否可以通过使它成为非聚集索引来提高速度（比没有索引更快但往往比聚簇索引慢一点，所以你的选择可能会减慢但插入改进）
我发现用户更愿意容忍稍慢的插入或更新到较慢的选择。这是一般规则，但如果它变得无法接受缓慢（或更糟糕的时候），没有人可以处理这个问题。