APM工具由之前的pinpoint切换为sw了，主要还是开发者是国内的，交流起来比较方便，并且社区也比较活跃。少说废话，下面直接开始。
切换sw后，发现某个实例性能不太好
1、复制一下慢接口的接口名称，到追踪里面查询慢接口的情况
在这里可以清楚看到基本上都需要好几秒，每次请求。在这个接口里面，做了好几次数据库的查询，其中第一次查询就3秒以上，用explain SQL语句，看看执行计划，发现了问题
没有走索引，尽管建立了联合索引，但是实际在执行查询的时候，没有走索引，而这个表的数据有好几百万。最简单的做法就是建一个索引，或者是修改查询语句，增加FORCE INDEX（索引），让这个语句强制走这个索引，针对条件建索引后，再看看执行计划，发现已经有了明显改变。
小科普：mysql的type效率差异顺序
type显示连接使用了何种类型。从最好到最差的连接类型为:
const、eq_reg、ref、range、indexhe和ALL
这里是显示range， range：这个连接类型使用索引返回一个范围中的行，比如使用>或<查找东西时发生的情况。
优化后，可以看到执行时间由之前的9秒左右下降到2秒左右
全链路的问题诊断和优化
我们知道，现在大部分都是微服务的架构了，但是微服务的问题排查简直是要人命，特别是在一些服务调用，还是调用的是其他产品线的服务，需要别人帮忙排查的时候，简直是求爷爷告奶奶的～～～～～。所以全链路的问题诊断和分析在微服务的治理中非常重要。这里也是以skywalking为例，看看如何分析和优化
在这里，我们可以看到某个服务基本上都是需要5秒以上（😓），这类请求会拖慢全站，关键的时候会导致雪崩效应，使得连接数爆了，所以这类服务必须消灭。
我们打开追踪的界面，看具体的连接情况
发现这里一共跨了2个应用，里面包含了51个事情（我的天呀，一个又长又臭的事务），紫色的是接口的入口网关层，我们可以看到网关大概是消耗3ms左右，剩下的5秒都是到具体的应用消耗的，网关层面上没有任何问题。而在业务应用层，可以看到51个事情基本上都是在做redis的处理，get，set和expire，而这些操作基本上都是1ms不到，redis层面是没有问题的（暂时不管set和expire的不合理问题，起码性能是好的），我们再观察一下右边的图形，你发现了啥？
哈哈，就是这里了，你发现在做完redis的一个get后，到下一个redis的操作set之间，差不多用了5秒，中间大量的真空。
打开具体的操作，看看是在获取哪个key里面的内容，方便查找问题
根据这个key，找到具体的代码，发现获取到内容后，里面有一个for循环去调用外部服务（汗ing）导致耗时过长，接下来就是具体的逻辑优化了，因为这里主要是讲如何利用工具跨应用去全链路分析具体问题在哪里。这里只是举例，只涉及到网关和一个业务应用，实际中会有跨多个应用的调用，主要都接入了skywalking，就可以用这个方法快速定位到是具体哪个应用，哪个逻辑慢或者出问题了。
