记一次线上mysql数据库卡死，排查修复过程

线上网站突发加载缓慢的情况，服务已经部署了很久，重启后无法解决问题。

排查路线：

        1.关闭服务器上其他服务，尝试访问，访问速度变快，以为是其他的服务影响，其实是假象。

        2.逐个测试其它服务的开启对网站的访问速度的影响，还真找到了一个多线程的数据更新服务，一开就卡死。（实际情况，后面才知道，该数据更新服务卡死只是表象）

        3.反复调试2中的数据更新服务，修改为单线程依然卡死，陷入自我怀疑中。整个调试过程中网站可以访问，发现数据库主要数据表插入、修改数据缓慢；

        4.于是怀疑是数据表数据量太大导致的，测试备份数据库同数据级别的相同表，修改、插入全都没有问题，调整数据库缓存等等；这个过程浪费了大量的时间（路走歪了）。

        5.数据更新服务急需上线，求助高手。以下是高手提供的思路：

（1）检查MySQL配置，全都正常，一般的默认配置应该都没啥问题；

（2）explain分析insert/update语句，由于使用的MySQL版本较低，这个没法执行；

（3）explain 分析select语句，查询正常；

（4）数据库执行show full PROCESSLIST，发现大量的表锁（这个我自己排查的时候也发现了，只是没有往网站的业务sql上想，光顾着调缓存了），由于是线上环境，网站服务没有关，有很多查询干扰。但可以确定是由于某些sql导致的表被锁，数据表引擎用的是MyISAM,使用的是表级锁。

（5）开启mysql慢日志，获取执行时间较长的sql记录

set global slow_query_log = 1 #开启慢日志
set global slow_query_log_file = /var/log/mysql/mysql-slow.log #设置慢日志存储目录
set global long_query_time = 3 #执行时间大于3秒会被记录

（6）拿到mysql-slow.log文件，果然找到一个分页查询语句，分页总数获取执行9s以上，分页数据查询limit起始位置超过了百万，执行时间9s以上。根据sql语句的功能，发现是网站中的业务代码中使用的，和上文提到的数据更新程序一点关系都没有。

（7）优化代码逻辑，对分页的后续数据进行限制，根据网站的业务分析，大概率是网站被爬虫给爬了，正常人谁往百万数据后翻页呀。

（8）重新上线，重启数据更新服务，恢复正常。

哎，折腾两天，恶意爬虫害人啊