sql - 在大型、频繁使用的表上运行更新

Question

我在 SQL Server 2005 中有一个不断插入的大表(约 1.7 亿行，2 个 nvarchar 和 7 个 int 列)。从性能的角度来看，一切正常，但每隔一段时间我必须更新表中的一组行，这会导致问题。如果我更新一小组数据，它可以正常工作，但是如果我必须更新一组 40,000 条左右的记录，则大约需要 3 分钟，并且由于插入开始失败而导致表上出现阻塞，这会导致问题。

如果我只是运行一个选择来取回需要更新的数据，我会在大约 2 秒内取回 40k 条记录。只是更新需要永远。这反射(reflect)在更新的执行计划中，其中聚集索引更新占用了 90% 的成本，而用于获取行的索引查找和顶部运算符占用了 10% 的成本。我正在更新的列不是任何索引键的一部分，所以它不像重新组织任何东西。

有人对如何加快速度有任何想法吗？我现在的想法是编写一个服务，它只会看到这些更新何时发生，拉回必须更新的记录，然后循环并一个一个地更新它们。这将满足我的业务需求，但它是另一个需要维护的模块，如果我能从 DBA 方面解决这个问题，我会很高兴。

感谢您的任何想法!

Answer 1

实际上，如果您更新 nvarchar 列，它可能会重新组织页面。
根据更新对这些列所做的操作，它们可能会导致记录增长到大于更新前为其保留的空间。
(现在参见说明 nvarchar 存储在 http://www.databasejournal.com/features/mssql/physical-database-design-consideration.html 。)

所以说一条记录有一个保存在 nvarchar 中的 20 个字符的字符串 - 这需要 20*2+2(2 个指针) 字节的空间。这是在初始插入表时写入的(基于索引结构)。 SQL Server 将仅使用 nvarchar 实际占用的空间。

现在更新并插入一个 40 个字符的字符串。哎呀，索引的叶子结构中的记录空间突然太小了。所以关闭记录到不同的物理位置，旧位置的指针指向更新记录的实际位置。

然后，这会导致您的索引过时，并且由于整个物理结构需要更改，您会看到很多索引工作在幕后进行。很可能导致排他表锁升级。

不知道如何最好地处理这个问题。就个人而言，如果可能的话，我会使用排他表锁，删除索引，进行更新，重新索引。因为您的更新有时会导致索引过时，所以这可能是最快的选择。然而，这需要一个维护窗口。