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