前言
-
平时在工作中每天都会做巡检，将前一天所有超过500ms的慢SQL排查出来
-
查找原因，是否能进行优化。慢慢中，在形成了一套思路方法论。
- 我个人认为对于排查慢SQL还是有一定的帮助
（一）、是否是SQL语句本身导致的慢SQL
- SQL语句是否走了索引。此条可以用explain命令查看
- SQL语句是不是select的数据量非常非常的大。比如是一个长长的json串，在网络传输的过程中会非常的耗时
（二）、SQL慢查询是否是其他外在因素导致的
-
如果SQL语句本身没有问题，大概率就是偶尔出现，其他因素影响的。
-
慢SQL这段时间，请求量是否很大，MySQL是否能支撑住此刻的访问量
- 此刻时间，是否有定时任务在大量操作数据库，造成锁表等？
-
是不是其他组执行了一条很长的操作，影响了你们的SQL
（三）、SQL慢查询是否只在一个机房出现
-
比如应用部署在了A, B两个机房。当时数据库在A机房。
-
此时A机房的应用请求数据库，明显会比B机房的应用，跨机房请求A机房的数据库要效果好。
- 此刻时间，是否只有跨机房才会出现慢SQL。同机房不会出现
（四）、SQL慢查询是否由于网络原因
-
比如应用到数据库并不是直连的，。应用 --> 中间件A --> 中间件B --> 数据库实例
-
应用到中间件A。此段网络是否正常，中间件A 到B是否正常，中间件B到数据数据库是否正常等等
- 可以用tcpdump抓包看看。是否出现了重传的现象，是否某一刻网络出现了问题等等