我工作的公司目前使用 SQL Server 数据库（通常是最新的企业版）用于我们开发的产品。
我会将它描述为一个 OLTP 数据库，它具有大量时间关键应用程序的读写密集程度。除此之外，根据同一 OLTP 数据库（单独问题）中的信息显示了大量报告和图形数据，这些数据以频繁的速率读取和写入许多相同的表。
我们通常会遇到发生阻塞的问题，并且通常最终会减慢时间关键应用程序的速度，甚至由于这些应用程序中的死锁而导致问题。这个问题的常见解决方案似乎通常是对nolock有问题的查询提出提示。老实说，我讨厌这个解决方案，很长一段时间以来，我一直认为这是尝试解决这个问题的错误方法，从我阅读的所有内容中，我得出了相同的结论。
一段时间以来，我一直试图说服我的团队 RCSI 是我们绝对可以从中受益的东西，特别是考虑到我们的数据库类型。他们似乎认为这是一个很大的风险，并且经常因为风险因素而推迟它，但我们继续遇到性能问题，我们只是nolock在暗示它。
我正在寻找一种向我们的团队展示具体指标的好方法，以最终说服他们我们应该转向这种方法。