【51CTO晃荡】8.26 带你与清华大年夜学、搜狗、京东大年夜咖们一路商量基于算法的IT运维实践

问题描述

经由过程 C AT 监控体系、SQL样本、慢萌芽体系等进一步懂得，发明这类SQL有如下特点:

• 根本上都是以主键或独一键为前提的简单萌芽，萌芽后的结不雅集及扫描的行数都比较小;
• 萌芽的表的数据总量也很小，最小的表甚至只有几千行;
• 时光达到了几百ms，甚至1s;
• 数据库的slow log琅绫腔有记录这类SQL。

下图为CAT相干监控数据的样本，以xxx-service这个service为例：

99line的监控数据，有很多SQL的返回时光跨越100ms以上。

每个问题总有它的界线。当我们无法一眼看出来问题的界线在哪里时，就须要赓续的经由过程清除法缩小界线，在特定的界线内就用特定的专业常识来定位问题。

SQL的绝对数量在2016年9月6日当天为 ：3788。

具体到某个SQL，甚至达到了929ms。

FB_Coach的表构造如下：

概要分析

要想定位到原因，必须经由过程清除法找到该SQL到底慢在哪个阶段，如许才能缩小范围。接下来我们来分析慢SQL的花费时光构成。大年夜下图可看出，时光重要由3部分构成：

• App Server：发出SQL请求的时光，接收返回结不雅的时光
• 收集：SQL请求包及萌芽结不雅在收集上花费的时光
• MySQL Server：发出SQL到萌芽结不雅全部过程花费的时光

我们可以经由过程抓包对象获取每个阶段花费的时光，大年夜而定位到底慢在哪个阶段。

问题解决思路迭代

办法：分别在APP Server与MySQL Server安排TcpDump抓包对象，获得数据包在4个监测点的“达到时光”。为了便利，把如下4个Wireshark分析结不雅(对TcpDump抓取日记分析)按4个方位标注：

• APP Server 发出SQL(左上)
• MySQL Server 收到SQL(右上)
• MySQL Server 将萌芽发出(右下)
• APP Server 收到萌芽结不雅(左下)

大年夜数据可以精确的看出时光重要花费在MySQL内部，具体时光为22.569285000-21.962634000=0.6066509999999994(秒)，约为606ms。

抓包结不雅： 慢在MySQL Server端。

可看到最多641笔记录，还有结合索引。

思路2： 一条SQL进入MySQL Server到萌芽结不雅输出分哪些阶段?

思路1：确认哪个过程花费的时光最多

办法： 将MySQL内部对SQL萌芽的流程进行梳理，采撤清除法定位问题。要 把经典图拿出来说事了，以下基本常识重要来自于《高机能MySQL》，“拿来主义”一下。

接下来经由过程一个客户端请求萌芽数据，看看MySQL重要做哪些工作吧。

每个客户端(可能懂得为App负责连接数据库的组件，我们叫DAL)连接到MySQL办事器过程后会拥有一个线程，这个连接的所有萌芽都邑在该线程中去履行，同时办事器会缓存线程，以削减创建或烧毁线程的开销和频繁的高低文切换。

当客户连接到MySQL办事器时，办事器会分派一个线程，之落后行权限认证，认证经由过程后，MySQL就开端解析该SQL萌芽，并创建内部数据数据构造(解析树)，然后对其各类优化，最后调用存储引擎API获取或存储须要的数据，最后将萌芽结不雅返回给客户端。

　　推荐阅读

　　微软Word漏洞：黑客可利用链接自动更新安装恶意软件

【51CTO晃荡】8.26 带你与清华大年夜学、搜狗、京东大年夜咖们一路商量基于算法的IT运维实践 根据外媒消息，SANS 互联网中间的一名自由安然参谋和 Handler 在微软 Word 中>>>详细阅读

本文标题：简单SQL也很慢？数据库端到端性能问题的解决思路探讨

地址：http://www.17bianji.com/lsqh/36869.html

 1/2    1