如何为这个需求设计数据库？
数据在一个表中。它也很高。我的应用程序启动了许多线程，所有线程都连接到数据库并更新同一个表；每个线程都会尝试更新不同的行。。。
然而，令人遗憾的是，由于进入死锁场景，更新操作没有完成。后来了解到，这可能是由于sql server的锁升级机制造成的。
简而言之，我的要求是我的数据库应该处理对单个表的大量更新操作。应对策略是什么？
我想，大规模的更新操作也会由于I/o而导致瓶颈。因为经典的硬盘只有一个磁头，它可以寻找存储在以每秒高转速旋转的磁盘上的数据。没有意识到这一领域的技术进步，但数据库设计师不会也关心这些问题吗？如何处理这些问题？
有人告诉我索引有帮助。。。但我觉得很难相信。。。
http://www.mssqltips.com/sqlservertip/2517/using-a-clustered-index-to-solve-a-sql-server-deadlock-issue/
如果您提供巨大和巨大的数字，那就太好了。只要总行数和更新数的比例很大，并且更新对所有索引的分布非常均匀，就应该不会有什么争用。
索引之所以有帮助，是因为您可以找到需要更新的确切行，而无需锁定所有其他行。因此，数千次同时更新中的每一次都会获得一个独占锁、几个独占意图和一堆共享锁。索引有帮助的另一个原因是，每个查询花费的时间很小，减少了活动事务的数量和死锁的机会。
由于您的更新只更新一行，因此如果您有完美的索引，实际上很难使它们死锁：更新除聚集键之外的所有内容，并且只在表上有聚集索引。如果你有多个索引，更新可以获取不同索引的一部分，并将彼此锁定。
如果你真的有磁盘问题，那么你需要获得更多的RAM。除非你的加载是真正随机的，没有任何时间位置，否则你的大多数更新都将从RAM提供，你唯一需要的磁盘访问就是写事务日志，这是一个只追加的日志，不需要磁盘随机搜索。
因此，如果你说的是优化这一点的一般策略，我会有一个代理集群密钥，确保更新只在这个密钥上搜索，不更新这个密钥，没有其他wueires，并且表上只有这个索引。然后，每个更新都只有一个排他行锁，而没有页面/数据块锁。永远不会出现僵局。
有很多方法可以解决这个问题
1） 如果您的更新不需要立即反映在表上，那么您可以放弃sql server，使用Hadoop或green-pleum等大数据技术，这将有效地为您解决这一问题。
2） 如果不满足，则尝试使用（ROWLOCK）进行更新，通常页面锁或表锁将由sql server获取，在进行更新时，上述提示可能会减少死锁。
3） 确保可以快速完成更新（性能调整）。
4） 根据良好的标准对表进行分区，使单个表表现为多个表，并减少争用。