如何将更新操作扩展到sql server表？

Question

如何设计您的数据库以满足此需求？

数据位于单个表中。它也相当高。我的应用程序启动了许多线程，所有这些线程都连接到数据库并更新相同的表；每个线程都会尝试更新不同的行……

然而，观察到的是，更新操作没有完成，因为它进入了死锁场景。后来了解到这可能是由于sql server的锁升级机制。

因此，简而言之，我的要求是我的数据库应该处理对单个表的大量更新操作。处理它的策略是什么？

我想，大规模的更新操作也会因为I/o造成瓶颈，因为传统的hardisk只有一个磁头，它在以每秒高转速旋转的磁盘上寻找存储的数据。没有意识到这一领域的技术进步，但数据库设计师不会也关注这些问题吗？如何处理这类问题？

Answer 1

如果你能提供大量的数据，那就更好了。只要总行和更新的比率很大，并且更新相当均匀地分布在所有索引上，就应该不会有什么争用。

索引之所以有用，是因为您可以准确地找到需要更新的行，而无需锁定所有其他行。因此，您的数千个同步更新中的每一个都将恰好获得一个独占锁、几个独占意图和一堆共享锁。索引有帮助的另一个原因是，每个查询花费的时间很少，从而减少了活动事务的数量和死锁的机会。

因为您的更新只更新一行，如果您有完美的索引，那么实际上很难使它们死锁:更新除聚集键之外的所有内容，并且只在表上拥有聚集索引。如果你有多个索引，更新可以抓取不同索引的一部分，并相互锁定。

如果你真的有磁盘问题，那么你需要获得更多的RAM。除非您的负载是没有任何时间局部性的真正随机的，否则您的大多数更新将从RAM提供，并且您唯一需要的磁盘访问是写入事务日志，这是一个不需要磁盘随机查找的仅附加日志。

因此，如果您所说的是以最佳方式执行此操作的一般策略，我将使用一个代理聚集键，确保更新仅在此键上查找，不更新此键，没有其他密钥，并且表上只有此索引。那么每个更新只有一个独占行锁，没有页/区锁。永远不会有死锁。

Answer 2

有人告诉我索引helps...but我发现很难相信...

http://www.mssqltips.com/sqlservertip/2517/using-a-clustered-index-to-solve-a-sql-server-deadlock-issue/

Answer 3

解决这个问题的方法有很多。

1)如果您的更新不需要立即反映在桌面上，那么您可以抛弃sql server，使用Hadoop或green plum等大数据技术，它们将为您有效地解决这一问题。

2)如果不满足，则尝试使用(ROWLOCK)进行更新，一般情况下，页锁或表锁将由sql server获取，在执行更新时，上述提示可能会减少死锁。

3)确保您的更新可以快速完成(性能调整)。

4)根据好的条件对表进行分区，使单个表表现为多个表，减少争用。