原创 记录一次线上Mysql慢查询问题排查过程
背景
前段时间收到运维反馈，线上Mysql数据库凌晨时候出现慢查询的报警，并把原始sql发了过来：
--去除了业务含义的sql
update test_user set a=1 where id=1;
表数据量200W左右，不是很大，而且是根据主键更新。
问题排查
排查Mysql数据库
我看到sql后第一反应就是是不是数据库出问题了，每个小时都有业务，偏偏白天业务高峰时间段正常，凌晨业务量很少时候出问题，让运维先检查了数据库的状态，反馈是数据库正常。
排查业务代码（第一次）
这块业务代码比较复杂，而且是别人写的，第一次看都没看完，直接在代码里打印了各个模块执行的时间，然后上线。
排查业务代码（第二次）
第二天又出现慢查询了，我赶紧下载了线上日志，发现整个方法执行时间很长，然后发现执行时间长的代码有几行调用其他服务的代码，使用的是HttpClient，猜到了原因，应该是调用其他超时导致的。
说下系统整体流程，微信（A）回调我们的收银台服务（B），收银台更新订单信息并调用业务服务（C）。
出问题原因是：
第一次A调用B，B锁住记录行并调用C，这个时候C没有响应，导致A又发送了第二次请求。
第二次A调用B，B更新记录时候发生死锁，出现慢查询。
解决方案
收银台系统B接收回调的方法添加分布式锁，保证同一时刻同一订单只能更新一次。
收银台调用业务服务使用的是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问题的？
原文地址
https://www.cnblogs.com/haha12/p/12580673.html
最近，开发人员需要定期的删除表里一定时间以前的数据，SQL如下：
mysql > delete from testtable WHERE biz_date <= '2017-08-21 00:00:00' AND status = 2 limit 500\G
前段时间在优化的时候，我们已经在相应的查询条件上加上了索引，如下：
KEY `idx_bizdate_st` (`biz_date`,`status`)
但是实际执行的SQL依然非常慢，为什么呢，我们来一步步分析验证下。
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB MySQL版解析与实践（下）——三、SQL优化与慢查询解决（上）
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB MySQL版解析与实践（下）——三、SQL优化与慢查询解决（上）
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB MySQL版解析与实践（下）——三、SQL优化与慢查询解决（下）
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB MySQL版解析与实践（下）——三、SQL优化与慢查询解决（下）
【MySQL从入门到精通】【高级篇】（二十二）慢查询日志分析，SHOW PROFILE查看SQL执行成本
上一篇文章我们介绍数据库的优化步骤【MySQL从入门到精通】【高级篇】（二十一）数据库优化步骤_查看系统性能参数，其中，说到了通过开启慢查询日志来分析慢查询的SQL。这篇文章就是具体来介绍如何开启慢查询日志以及如何分析慢查询日志。
对于生产业务系统来说，慢查询也是一种故障和风险，一旦出现故障将会造成系统不可用影响到生产业务。当有大量慢查询并且SQL执行得越慢，消耗的CPU资源或IO资源也会越大，因此，要解决和避免这类故障，关注慢查询本身是关键。
