如何设计你的数据库来满足这个要求？
数据在一个表中。它也相当高。我的应用程序启动了许多线程，所有这些线程都连接到数据库并更新同一个表；每个线程都会尝试更新不同的行...
然而，令人担忧的是更新操作没有完成，因为它进入了死锁场景。后来才知道这可能是由于sql server的锁升级机制造成的。
所以简而言之，我的要求是我的数据库应该处理对单个表的大量更新操作。有什么应对策略？
我想，大规模更新操作也会因 I/O 造成瓶颈。因为经典的硬盘有一个磁头，它可以寻找存储在磁盘上的数据，该磁盘以每秒高转速旋转。不知道这方面的技术进步，但数据库设计师不会也关心这些问题吗？如何处理这些问题？
【问题讨论】：
标签： sql-server scalability deadlock updates
【讨论】：
如果您提供大量的数字，那就太好了。只要总行数和更新的比率很大，并且所有索引的更新分布相当均匀，那么争用应该很少。
索引之所以有帮助，是因为您可以找到需要更新的确切行，而无需锁定所有其他行。因此，您的数千个同时更新中的每一个都将获得一个排他锁、一些排他意图和一堆共享锁。索引有帮助的另一个原因是每个查询花费的时间很少，从而减少了活动事务的数量和死锁的机会。
由于您的更新只更新一行，如果您有完美的索引，实际上很难让它们死锁：更新除聚集键之外的所有内容，并且只在表上使用聚集索引。如果您有多个索引，则更新可以抓取不同索引的部分并相互锁定。
如果您确实遇到磁盘问题，那么您需要获得更多 RAM。除非您的负载是真正随机的，没有任何时间局部性，否则您的大部分更新都将从 RAM 提供，并且您唯一需要的磁盘访问是写入事务日志，这是一个仅附加日志，不需要磁盘查找随机。
因此，如果您说的是最佳执行此操作的一般策略，我将有一个代理集群键，确保更新仅在此键上搜索，不更新此键，没有其他 wueires，并且只有这个表上的索引。然后每次更新都只有一个排他行锁，没有页/范围锁。永远不会出现僵局。
【讨论】：
有很多方法可以解决这个问题
1) 如果您的更新不需要立即反映在表上，那么您可以放弃 sql server 并使用 Hadoop 或 green plum 等大数据技术，它们会有效地为您解决这个问题。
2）如果不满足，则尝试使用（ROWLOCK）进行更新，一般情况下页锁或表锁会被sql server占用，更新时，上述提示可能会减少死锁。
3) 确保您的更新可以快速完成（性能调整）。
4) 根据良好的标准对表进行分区，以便您的单个表表现为多个表，并减少争用。
【讨论】：