系统隐形杀手-阻塞和等待（SQL）

前言

应用系统携带大量的服务，其次是复杂的业务逻辑，数据库上有大量不同类型的SQL语句。

SQL语句执行的速度也与阻塞等待不可分割。

慢系统可能有很多原因，硬件资源不足，报表不优化，结构设计不合理，缺乏必要的操作和维护方法，这些问题都存在于阻塞等待、发现和解决问题中。

今天我们主要讲的是如何查找和解决系统的阻塞和等待。

场景描述

你的系统有这样的问题吗

系统运行速度慢，很多功能需要几十秒来显示结果，用户体验很差。领导们不断地施压，作为系统的负责人，他们只知道系统很慢，不知道慢在哪里，我们不能解决问题，我们必须引导或习惯于不满的声音。慢，没有反馈。
系统的功能运行缓慢，语句在生产环境中运行很长，但它是否在测试环境中快速运行，或者仅使用此语句这似乎不科学。
我对数据有了更多的了解，我可以了解系统的等待情况。但我不知道这些等待意味着什么。百度的答案不能解决很多问题。
我可以找到并等待解决这部分等待，但只有通过一些脚本，我们不能完全了解现状。我们只能参加游击战争。
我是一个专家问题，我都能解决，但我不能直接介绍给领导。
系统等待简介

一个好的SQL语句就像一辆好的汽车，时速180。良好的系统硬件（CPU、内存、磁盘）就像一条平坦宽阔的道路，它看起来像一辆好车，它的路很好，而且速度很快！事实上，有点被忽视了！当你开的是法拉利在北京的一个大三圈，即使你是三环和十二少老炮，多少晨峰你能到北京吗北京的早期高峰！

这个例子引出了系统阻塞和等待的概念，红灯（硬件等待，如IO等待），这是正常的等待。另一辆车不走或在你前面开得很慢，所以你只能等待（你可以说是被他挡住了）！

一张图片告诉你系统的主要类型和解决方法。
问题诊断

任何问题的诊断是从全球的角度来看，最忌讳的就是看到的位置高的指标，然后分析问题的泛化。

一个问题点可能涉及很多方面，所以我们首先需要从全局的角度来定位系统问题。阻塞也是如此。系统中存在哪些堵塞现象，主要原因是什么

全球定位阻塞和等待

首先，我们需要关心数据库中等待类型的类型。
注意：本部分介绍了系统中的等待情况，类似于使用脚本。它排除了不必要的关注类型，并对等待进行分类统计。

Abscissa：等待型

纵坐标：集合期间出现的次数。

知道如何等待类型，我们想知道哪种类型需要花费很多时间：
注：各种等待类型的等待时间也是调查的主要方向。再加上等待类型和等待时间，我们可以知道等待和等待是严重的，哪些是最严重的。

Abscissa：等待型

坐标：平均等待时间

要理解等待和时间的主要类型，我们还需要分析：数据库是从哪里来的手续是什么用户请求的结果是什么什么时候最严重
等待的具体陈述

整个系统的等待情况是清楚的。下面我们来看看等待产生什么语句，这也是解决问题的一个重要的分析步骤。

什么样的句子最频繁
注意：这里我们可以根据不同的时间、等待时间、等待资源消耗、阻塞类型语句的多维分析来排序。

声明的具体等待情况是什么我们可以在原始视图执行特定语句时查看真正的阻塞情况。
注意：在阻塞的详细视图中，我们可以清楚地看到语句的阻塞树，并且可以看到阻塞语句、时间、资源被阻塞、等待类型。

阻塞树：在本例中，会话68被会话66阻塞，会话66被会话104阻塞，因此3会话形成阻塞链，也称为阻塞树。

诊断结论

通过全局定位、句子类型分析和具体语句执行阻塞状态，通过对阻塞类型、时间、时间、连接过程、资源消耗等维度的综合分析，可以清晰地看到数据库中的阻塞问题。

在这种情况下，主要的堵塞类型的系统cxpacket和lck_m_u，和阻塞时间很长。主要阻塞时间为上午十一点左右，主要阻塞语句是更新和复杂的SELECT查询。

解决问题

首先，下图简单说明系统相应的等需要解决的问题。 U3000 U3000
注：根据不同的情况，减少拥塞的方法是调整服务器实例，数据库配置参数（例如，调整平行），更改隔离级别（例如，快照读NOLOCK、等），优化的句子（例如，添加索引，优化写作方法等）。

在这种情况下，该cxpacket主要是由于并行参数配置的例子是可怜的，lck_m_u主要是更新了一批又一批更新阻塞锁的原因，优化更新，这种更新的声明主要是为了保证更新语句的优化，尽量缩短执行时间，高并发更新更常见解决方案是使用代表性指标锁提高关键的并行使用，可以更新几十条记录，添加索引和并行效率指标会有很大的不同。另外，程序设计也很重要，你所有的秘密在实际环境中缓慢，和SQL专家云工具的使用，主要目的所有的定位，以及其他形式的统计图表清楚地显示了问题，并根据工具提供快速解决问题的解决方案。
以上是本文的全部内容，希望本文的内容能给大家的学习或工作带来一定的帮助，同时也希望能给予更多的支持！