我正在查看一个大小为 751 GB 的 SQLServer 数据库，该数据库在全球 100 个国家/地区拥有多个用户进行访问。
自过去几个月以来，该数据库在几个表上遇到了死锁。
我怀疑这个巨大的大小可能会对数据库锁产生影响。在选择查询中使用时，我查看了索引和存储过程并在表上应用了update lock。
仍然没有影响。
【问题讨论】：
标签： sql sql-server performance deadlock
如果有用户仅将表用于报告目的（并且他们查询的数据变化不会太快），他们总是可以使用 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 函数。
这不会在运行 select 语句时锁定表。但是，您确实需要明智地使用它……因为许多 SQL 专家会告诉您，您的结果可能不正确。但是，它可能有助于减少您看到的死锁数量。
查看此页面了解更多信息https://en.wikipedia.org/wiki/Isolation_%28database_systems%29#READ_UNCOMMITTED_.28dirty_reads.29
【讨论】：
您需要分析发生死锁的位置。它与您的数据库的大小（或在多少个国家使用它）本身无关。这只是访问数据的问题以及使用数据库的应用程序的行为模式。
当一个进程正在读取记录而另一个进程正在更新它们时，通常会发生死锁，并且它们都需要对数据获取更多锁，但由于另一个进程已经对这些行拥有锁并且在另一个完成之前，它们中的任何一个都不能继续 - 那时 SQL Server 会注意到问题并发生死锁。
死锁可能发生在数据或索引上，你应该检查它是哪一个，它可能会帮助你弄清楚发生了什么。
为了解决这个问题，如果您可以更改模式以便始终以相同的顺序访问数据，则不应出现死锁。
另一种方法是查看语句并查看涉及多少 I/O。如果语句涉及例如扫描，则创建新索引可能会解决问题。那么该进程需要访问的页面会大大减少，死锁的机会也会减少。
如果是繁忙的数据库，并且一直在同一张表上发生许多不同的操作，可能无法摆脱所有死锁，因此您还应该提出一个目标，多少死锁是可以的。
我个人会远离脏读（隔离级别读取未提交/使用 NOLOCK），但在一些非常特殊的情况下使用它可能会有所帮助，因为它也会导致严重的副作用，比如读取相同的数据不止一次。这当然在很大程度上取决于您正在处理的数据/应用程序的类型。
【讨论】：