如何处理锁定信息？

Question

由于分析了几个死锁，我使用sp_blitzIndex来获得关于锁的概述。

受死锁影响的表(和视图)与被诊断为

“进攻性索引:总锁等待时间>5分钟(行+页)” (解释)。

在那里，建议检查那些表上缺少的索引。好的，对于这些表，确实存在Sql Server建议的具有很高潜力的错误索引.

但是我实际上是在试图理解sp_BlitzIndex给出的信息的确切含义以及它们出现的原因。

以下是死锁链和“积极索引”中出现的一些示例：

dbo.O.IX_O1 (48)：页锁等待: 133；总持续时间:5分钟；平均持续时间:2秒；锁定升级尝试: 98；实际升级: 19。dbo.O.IX_O2 (57)：行锁等待: 468；总持续时间:5分钟；平均持续时间:0秒；

dbo.O是一堆。

dbo.P.IX_P1 (18)：行锁等待: 6；总持续时间: 19秒；平均持续时间:3秒；页锁等待: 52；总持续时间:4分钟；平均持续时间:5秒；锁定升级尝试: 196；实际升级: 19。dbo.D.IX_D1 (14)：行锁等待时间: 587；总持续时间: 30分钟；avg持续时间:3秒；锁定升级尝试: 30；实际升级: 0。dbo.S.PK_S (2)：行锁等待: 697；总持续时间: 44分钟；平均持续时间:3秒；锁定升级尝试: 709；实际升级: 1. dbo.E.IX_E1 (18)：行锁等待: 108；总持续时间:5分钟；平均持续时间:3秒；锁定升级尝试: 4；实际升级: 0。

问题：

1. 不幸的是，布伦特·奥扎尔并没有真正解释它们的意义和解决办法，除了重新调整指数。那么，这意味着什么，为什么会出现呢？这主要是因为这些表上的读和/或写太慢了，由此产生的锁花费了太多的时间吗？
2. 如果我继续添加影响最大的缺失索引--这不是只会增加执行insert / update语句所需的时间吗?也许这样会增加陷入死锁的机会--或者反过来，为表删除未使用的索引会因为I/U语句更快而减少死锁的可能性吗？

Answer 1

过多的锁和死锁有几个常见的嫌疑人。服务器抱怨缺少索引这一事实很大程度上暗示了当前的索引策略是不够的，因此表O、P、D、S和E发生的任何事务都是需要完成的，因此增加了升级的机会等等。尝试使用SET STATISTICS IO ON运行一些有问题的语句。它们很可能有非常多的物理读取，而不是高逻辑读取，这表明磁盘IO很高。

将此与大量并发事务相结合可以增加死锁的可能性。一个好的事务设计的经验法则是使它尽可能的快速和简短。它可能有助于您重新查看基本知识，并更新您的死锁和锁升级的知识。

• 锁升级
• 最小化死锁指南

您对索引插入性能下降的关注是可以理解的。索引确实会降低insert和update等操作的性能，因为页面可能需要拆分、重新组织和调整，但只有在索引太多的情况下才会如此。适当设计索引将极大地提高IO性能。通过添加一个能够支持问题语句的索引进行测试；一个没有索引，另一个有。您可以使用SET STATISTICS TIME ON获取实际时间。

但是仅仅拥有一组好的索引是不够的。毕竟，您的语句必须设计为通过使谓词与索引一起工作来利用它们。当任何一个都没有时，您的查询性能将受到极大的影响。除了检查索引之外，我还建议检查SARGs的正确使用情况。

如果没有看到使用情况统计数据，我就不能建议您删除其他索引。我建议你看看这个博客关于如何查找索引用法的提示

Answer 2

我建议你读了解服务器如何执行查询。

我不能评论布伦特的记事本，但我可以告诉你在sys.dm_数据库_索引_运营_统计数据中的等待统计信息。每hobt等待统计，聚合页和行锁等待信息和页锁和io闩锁信息。这里的高数字表示争用(许多试图在同一页/行上操作的并发事务)或扫描(操作锁定和锁定所有页面)。在你的例子中，问题似乎是扫描。当每个操作都读取整个表时，会导致大量的锁定、锁存和可能的IO。通过将扫描转化为查找，索引将显着地减少这些数字。

更有甚者：

• 如何分析Server的性能
• 服务器索引设计指南