原创 记录一次线上Mysql慢查询问题排查过程

背景

前段时间收到运维反馈，线上Mysql数据库凌晨时候出现慢查询的报警，并把原始sql发了过来：

--去除了业务含义的sql
update test_user set a=1 where id=1;

表数据量200W左右，不是很大，并且是根据主键更新。

问题排查

1. 排查Mysql数据库

我看到sql后第一反应就是是否是数据库出问题了，每一个小时都有业务，恰恰白天业务高峰时间段正常，凌晨业务量不多时候出问题，让运维先检查了数据库的状态，反馈是数据库正常。

1. 排查业务代码（第一次）

这块业务代码比较复杂，并且是别人写的，第一次看都没看完，直接在代码里打印了各个模块执行的时间，而后上线。

1. 排查业务代码（第二次）

次日又出现慢查询了，我赶忙下载了线上日志，发现整个方法执行时间很长，而后发现执行时间长的代码有几行调用其余服务的代码，使用的是HttpClient，猜到了缘由，应该是调用其余超时致使的。

说下系统总体流程，微信（A）回调咱们的收银台服务（B），收银台更新订单信息并调用业务服务（C）。

出问题缘由是：

第一次A调用B，B锁住记录行并调用C，这个时候C没有响应，致使A又发送了第二次请求。

第二次A调用B，B更新记录时候发生死锁，出现慢查询。

解决方案

1. 收银台系统B接收回调的方法添加分布式锁，保证同一时刻同一订单只能更新一次。

2. 收银台调用业务服务使用的是HttpClient4.4，默认超时时间60秒，这么长时间若是对方没有响应就完了，改为了5秒，超时立马返回，不影响其余业务。

HttpClient4.4版本设置超时时间代码以下：

HttpPost httpPost = new HttpPost(url);
 RequestConfig.custom().setSocketTimeout(5000).setConnectTimeout(5000).setConnectionRequestTimeout(5000).build();
 httpPost.setConfig(requestConfig);

上面设置了3个超时时间，含义以下：

setConnectTimeout：设置链接超时时间，单位毫秒。

setConnectionRequestTimeout：设置从connect Manager获取Connection 超时时间，单位毫秒。这个属性是新加的属性，由于目前版本是能够共享链接池的。

setSocketTimeout：请求获取数据的超时时间，单位毫秒。 若是访问一个接口，多少时间内没法返回数据，就直接放弃这次调用。

最后，按照这两个方案改造上线后，系统运行正常，问题解决。

推荐阅读

1.用户密码到底要怎么加密存储？ 2.完全理解cookie、session、token 3.阿里面试官：分别说说微信和淘宝扫码登陆背后的实现原理？ 4.一分钟带你了解下MyBatis的动态SQL！ 5.原创 | 我是如何解决POI解析Excel出现的OOM问题的？

---

若是以为文章不错，但愿能够随手转发或者”在看“哦，很是感谢哈！

关注下方公众号后回复「1024」，有惊喜哦！

原文出处：https://www.cnblogs.com/haha12/p/12580673.html