DB“慢查”排查记
上面讲了一些配置的坑，那么是否中规中矩的按照推荐配置就万事大吉了呢，现实中的世界往往没这么简单的事，下面分享一个“慢查”排查的一个案例，了解一下DB慢查的排查思路。
有应用反馈发现大量DB慢查，并且日志上还记录了详细的执行时间和SQL语句。接到问题后我们第一时间排查DB发现并没有异常，也没有慢查记录，并且日志中的大部分SQL都能匹配索引，测试执行都在毫秒级。于是开始排查网络是否正常，有没丢包、重传等现象，查询监控数据发现也很正常，然后进行抓包分析发现实际请求处理的速度非常正常，至此可以排除DB问题。
于是再深入分析，查询DB其实可分为两个阶段：1. 获取连接阶段； 2. 执行查询阶段；绝大部分情况下获取连接代价非常小，直接就能从连接池获取到，即使需要新建连接代价往往也不大，所以使用时非常容易忽略获取连接这个阶段。什么情况下获取连接会出问题呢？一种情况是建立连接慢，一种是连接池已经耗尽，再对照上面的案例进行排查，依次排除了这两种情况。至此问题还是一筹莫展，还好高手在场，想到用 strace 跟踪 SQL 请求前后干了什么，最后发现记录慢查日志开始和结束之间有写日志操作，这里的写日志是同步的并且在特定情况下正好触发了另个问题导致写日志非常慢，并且这个日志操作是封装在底层的，连业务开发都不清楚有这么个操作。至此真相水落石出，最终修复了写日志慢的问题后就不再出现类似的“慢查”了。
若有收获，就点个赞吧
0 人点赞
