背景问题： s服务器（Windows系统）数据库一大早就搞事情，刚远程上时很慢，很卡。用户反映操作异常，卡慢 无响应。因为服务器机房网络出现过不好。就习惯性的以为是网络问题，后来发现不对劲，查看cpu100% 左右，看进程是mysqld占用99%。第一反应是锁表了。使用sql语句
SELECT * FROM information_schema.innodb_trx
SELECT * FROMINFORMATION_SCHEMA.INNODB_LOCKS;
show PROCESSLIST
show status like '%lock%'
show OPEN TABLES where In_use > 0
SELECT * FROMINFORMATION_SCHEMA.INNODB_LOCK_WAITS;
SELECT
a.trx_id,
trx_state,
trx_started,
b.id AS thread_id,
b.info,
b.user,
b.host,
b.db,
b.command,
b.state
FROM
information_schema.`INNODB_TRX` a,
information_schema.`PROCESSLIST` b
WHERE a.trx_mysql_thread_id = b.id
ORDER BY a.trx_started;
结果发现没有锁表。查看MySQL 错误日志 报错如下
网上给出的解决方案是这样的，因为是线上环境，对不了解的参数还是慎重为好。并且根据实际情况，我并不认为是此原因导致cpu暴涨。但还是照此思路排查了一下
Show global variables like ‘%innodb_page%
根据我对服务器的了解，该服务器因为是虚拟机cpu 和 io性能都很差。
Show global variables like ‘%innodb_lru%’
所以设置成512观察一下。但是这个原水可解不了近渴。现在必须想办法让cpu立即降下来
使用show processlist
发现有个个查询语句很多都是sending data 状态且时间很长
关于状态参考：https://blog.csdn.net/p656456564545/article/details/53169565
http://www.cnblogs.com/huangye-dream/archive/2013/05/30/3108298.html
kill 掉几个后，cpu果然降下来了。终于找到罪魁祸首了。
此查询语句大量的sending data 原因可能是服务器上述原因 还有可能是sql语句的查询效率问题。因此，又需要看下慢查询日志，发现一条查询语句时间到达500秒，看来真正的原因就是这条语句。于是在错误日志里筛选，发现同一语句只在昨天和今天出现过，并且最小查询时间100多秒，最大的500秒。
分析这个查询语句发现查询的数据太多了，都是百万条以上的，然后和开发沟通一下，对此语句要查询的数据进行了部分删除。以后可以定期删除该数据，因此分区又是一种选择，方便定期清除。
