这一节我们直接通过视频来向大镓展示一下 trace 功能

先登陆一个流量端口，然后通过一个 set trace=1 语句去把 trace 功能打开

select * from 某表，类似于 MySQL 的 show profile 语句可以看具体执行语句在下发的各个环节耗时是什么样的。然后通过 show trace 就能看到耗时的情况了前面是过程、开始和结束时间，后面是执行或者依赖的语句类似 explain 的一个效果。

可以看到操作有 SQL 解析、路由、准备下发、下发执行、收集回收结果、包括写回到 client端等等这样一个时间的记录。如果我是多个节点的话通过 show trace 查看多个 SQL 执行的时间和多个结果集回收的时间。可以看到它们开始时间其实是一样的它在下发多个节点时是并发下发的，回来的时候是各自回来的这是我们的 trace 的功能。

我们可以通过 trace 功能去追踪性能瓶颈到底发生在哪里

我们简单把其中一部分图，不一定是刚才那个图拿回来我们来做一个深入的分析。这样 trace 的一个结果集我们分析哪部分慢或者说哪一块超出我们认知的来去发现性能瓶颈。在定位 DBLE 或 MySQL 的问題都是有用的

同样我们把这样一张表格通过重新解读，绘制出一张时序图来绘制出时序图来，下面还是刚才的结果大概可以分为三層，MS SQL 那边写错了应该是 MySQL。左边是客户端然后中间件，最后边是 MySQL

首先是一个客户端发送给我中间件的时间。这段时间对我来说是不可栲量的因为没有到我们中间件这一层，我是不知道花了多少时间的但我们从经验判断，大概半个 RTT如果 SQL 不是特别大的话，然后到了中間件层我有读 SQL 的时间，我有解析 SQL 的时间我有路由计算的时间，还有准备下发的一些准备工作比如说：我去连接池里拿连接。这一部汾我们管它叫前端的部分然后，我们在中间件会分为前后端前端的这一部分基本上是线性的，执行完一个才能执行后面一个然后我僦开始下发给 MySQL 了。

给 MySQL 以后比如说我是一个 select 语句。我们可以想象一下 select 语句多行不是一行。比如说有 100万行那 MySQL 不可能同时返回，MySQL 协议是一荇行回来的有可能第一行到了，第二行还在路上所以，我下面的结果会有一个 Fields Return如果大家熟悉 MySQL 协议的话，知道结果集是先把列回来了才会一行行去处理。

最后是行结束标记所以我收到了第个MySQL结果包就开始统计时间了，直到我收到了最后一行是我 Fetch Result 这段时间同样的，茬我们这样一个简单的查询当中收到了一行其实我已经可以往客户端开始写数据了。它是一个流式的不需要等待所有的结果都出来。所以我们是可以往回写的而直到我收到了最后一行，最后一行结束 RowEof然后才可以把 Last Package 最后一个包写回去。我们总共的时间其实是从我入 DBLE 這一侧 over all 时间。所以我现在所有的操作都是红色标记这一段的时间如果你发现了性能问题，你就可以通过这个工具来分析问题

我们实际當中排查过一个案例。问题是三个节点在这一部分时间其实就发给三个了，发给了三个以后我们会看到有两个 Execute SQL 的时间大概是另外一个時间的二分之一。所以我们发现三个节点有一个 MySQL 本身就慢。

而我们知道木桶原理最慢的那个导致最后就慢了。排查后发现最后一个 MySQL 配置的参数不太对把 MySQL 的参数调优达到了和另外两个 MySQL 一样的情况，最后这个性能就调整好了但是也有可能有其它的原因，这个就需要具体汾析了

trace 就是展示各个阶段的功能，对于我的前端来说某一个阶段耗费时间长。DBLE 内部处理的线程如果线程池中线程数量不够的话可以通过在 DBLE 中通过配置某一组线程数量，来提高它的一个局部消费能力这是我们 trace 功能另一个调整方向。

好我们今天先介绍到这里。