背景問題： s服務(wù)器（Windows系統(tǒng)）數(shù)據(jù)庫一大早就搞事情，剛遠(yuǎn)程上時(shí)很慢彪置，很卡。用戶反映操作異常蝇恶，卡慢 無響應(yīng)拳魁。因?yàn)榉?wù)器機(jī)房網(wǎng)絡(luò)出現(xiàn)過不好。就習(xí)慣性的以為是網(wǎng)絡(luò)問題艘包，后來發(fā)現(xiàn)不對(duì)勁的猛，查看cpu100% 左右，看進(jìn)程是mysqld占用99%想虎。第一反應(yīng)是鎖表了卦尊。使用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;
結(jié)果發(fā)現(xiàn)沒有鎖表。查看MySQL 錯(cuò)誤日志 報(bào)錯(cuò)如下
網(wǎng)上給出的解決方案是這樣的舌厨，因?yàn)槭蔷€上環(huán)境岂却，對(duì)不了解的參數(shù)還是慎重為好。并且根據(jù)實(shí)際情況裙椭，我并不認(rèn)為是此原因?qū)е耤pu暴漲躏哩。但還是照此思路排查了一下
Show global variables like ‘%innodb_page%
根據(jù)我對(duì)服務(wù)器的了解，該服務(wù)器因?yàn)槭翘摂M機(jī)cpu 和 io性能都很差揉燃。
Show global variables like ‘%innodb_lru%’
所以設(shè)置成512觀察一下扫尺。但是這個(gè)原水可解不了近渴。現(xiàn)在必須想辦法讓cpu立即降下來
使用show processlist
發(fā)現(xiàn)有個(gè)個(gè)查詢語句很多都是sending data 狀態(tài)且時(shí)間很長
關(guān)于狀態(tài)參考：https://blog.csdn.net/p656456564545/article/details/53169565
???????????????????? http://www.cnblogs.com/huangye-dream/archive/2013/05/30/3108298.html
kill 掉幾個(gè)后炊汤，cpu果然降下來了正驻。終于找到罪魁禍?zhǔn)琢恕?/p>
此查詢語句大量的sending data 原因可能是服務(wù)器上述原因 還有可能是sql語句的查詢效率問題弊攘。因此，又需要看下慢查詢?nèi)罩竟檬铮l(fā)現(xiàn)一條查詢語句時(shí)間到達(dá)500秒襟交，看來真正的原因就是這條語句。于是在錯(cuò)誤日志里篩選伤靠，發(fā)現(xiàn)同一語句只在昨天和今天出現(xiàn)過捣域，并且最小查詢時(shí)間100多秒，最大的500秒宴合。
分析這個(gè)查詢語句發(fā)現(xiàn)查詢的數(shù)據(jù)太多了焕梅，都是百萬條以上的，然后和開發(fā)溝通一下形纺，對(duì)此語句要查詢的數(shù)據(jù)進(jìn)行了部分刪除丘侠。以后可以定期刪除該數(shù)據(jù)，因此分區(qū)又是一種選擇逐样，方便定期清除蜗字。
