线上故障 | 一条 SQL引起的血案

欢迎关注公众号【sharedCode】致力于主流中间件的源码分析，能够直接与我联系java

事故现场

202-11-19 系统接收到大量的超时告警，同时业务群里面也有不少客户反馈服务不可用。mysql

开始排查

首先上grafana上面查看总体的服务状态，算法

从图中能够看出一点问题来，CPU几乎没有波动， tomcat线程数急剧上升, 系统的ops急剧降低。这种是比较典型的资源阻塞类问题，为了印证这个想法，咱们再看下当时的系统的GC状况sql

从上面的GC状况下，咱们能够看出来，GC仍是比较平稳的，总体的停顿市场也很少，平均在100ms如下，虽然不算好，可是确定不会形成系统有如此大的停顿缓存

服务器出现故障排查方法：tomcat

服务器出现故障，先看CPU，若是CPU持续高涨，那么确定是服务内部出现了问题，这个时候能够按照网上的常规解决方法，top -HP pid 查看耗CPU比较严重的线程，而后导出对应的线程栈信息，就能够根据实际的业务去分析了，这种属于比较直观的服务器

比较隐晦的资源阻塞问题，此类问题分为以下两种：函数

比较好排查的，即便接口慢，好比接口调用耗费时间久的外部接口，有大量慢SQL，这些都会间接的致使总体吞吐量降低，最终致使tomcat线程池线程池耗尽
第二种就更加隐晦了，CPU，带宽，流量，慢SQL，内存各方面都很正常，可是tomcat线程池直线上升，最终服务器资源耗尽。这种状况我以前有专门写过一片文章。《tomcat线程池排查》这种状况能够考虑使用jstack命令，导出堆栈信息，这里推荐一款工具 gceasy ，能够清晰的分析出线程的状态分布，能够很好的知道线程都堵在什么地方了。

经过上面的已知条件和咱们过往的经验，基本上能够断定是有一些接口阻塞致使总体系统处理能力急剧降低。首先想到的就是慢SQL。工具

登录到阿里云的RDS控制台上，查看RDS的运行情况oop

果不其然，在那个时间段，CPU已经到了100%了，基本上能够肯定是慢查询的问题，在慢查询的控制台上，立马能够看到当前系统阻塞的SQL。触目惊心，真的不知道是哪一个兔崽子写的SQL。

罪魁祸首就是这条SQL

SELECT
	o.* 
FROM
	`jm_order` o
	LEFT JOIN jm_order_unregistered_driver d ON o.number = d.orderNumber 
WHERE
	o.valid = 1 
	AND o.state = 1 
	AND o.driver_uid = 0 
	AND o.agents_uid = 0 
	AND d.driverPhone IS NULL 
	AND o.is_push_regular_car = 0 
	AND o.is_lock = 2 
	AND (
		o.from_date > '2020-11-18' 
		OR (
			o.from_date = '2020-11-18' 
			AND o.from_day >= 16 
		)) 
	AND o.type IN (
	11,
	12)

经过explain关键字查询执行计划

问题一目了然了，看我红线框起来的地方，这个就是问题所在，咱们能够分析下这个SQL，这个SQL

里面有两张表，使用了left join ，其余的却是没什么问题，看索引走向以及扫描函数，其实看上去都没啥问题，不该该耗时这么久。

可是看红色框起来的部分Using where; Using join buffer (Block Nested Loop) , 这句话什么意思？

下面给你们讲一下mysql在表链接的时候使用的算法，同时也让你们理解一下为何有小表驱动大表的说法

mysql表关联算法

Simple Nested Loop算法

这个算法，属于简单嵌套循环，说白了就是外层表的结果做为第一层循环，内层表做为第二层循环，而后就这样硬干，

for (Table t:table) {
  for(Join x:joinTable){
    if(t==x){
      //xxxx ，说明匹配到了数据
      for(){
        // 若是有三种表关联的话。
      }
    }
  }
}

上面这种暴力关联的方法，可想而知效率那是差的一逼，基本上mysql官方也不会使用这种方式的。

执行顺序：

先遍历table1
遍历table获得的结果，逐条遍历table2
遍历完table2以后呢，继续逐条遍历table3, 返回最终的结果

执行次数基本上是： table1 * table2 * table3

Block Nested-Loop

这种算法，就是本文中生产环境实际遇到的，mysql默认在没有创建索引上面使用的算法, 这种作法和简单嵌套循环有一点不一样，就是加了 缓存块 ，减小了循环次数，将驱动表的数据缓存到 join Buffer里面去，而后拿Join Buffer 里面的数据和内层关联表进行匹配，

for (Table t:table) {
  // store t in Join buffer ,
  // 当缓冲池满了，执行匹配
  if(Join Buffer is full){
    for(Join x:joinTable){
    if(t in Buffer){
      //xxxx ，说明匹配到了数据
      for(){
        // 若是有三种表关联的话。
      }
    }
    clear join buffer // 清空缓存池
  }
  }
  
}

从这里能够看到，使用了缓存池的话，减小了不少次数，好比：驱动表100条数据，被驱动表50条数据，那么若是没有Join Buffer的话，读表次数：100 * 50，加了Join buffer以后，若是Join buffer的大小能够存储50条数据，那么读表次数就是： 100/50 * 50 ，读表次数减小了一个数量级的。

须要注意的是，只有在 连表键上没有索引的时候会采用这种方式 ，也就是本文出现的状况。

Index Nested-loop

索引嵌套循环，简称 INL，说白了就是 连表键上有索引，就直接走索引去作嵌套查询 ，下面我画一张图来解释

驱动表获得结果以后，是直接去索引树上找对应的被驱动表的记录，若是可使用覆盖索引的话，那么就不用再作回表了，这种状况下，效率是至关高的。

得出以上结果，立马给orderNumber 加上索引，走索引嵌套算法就能够了，系统立刻就恢复正常了。

看完上面的文字，这下你们明白了为啥有小表驱动大表的说法吗？

欢迎关注公众号【sharedCode】致力于主流中间件的源码分析，能够直接与我联系