客戶現場反饋，top的檢查結果中，一個CPU的占用一直是100%。實際上現場有4個CPU，而且這個伺服器是mysql專屬伺服器。 我的第一反應是io_thread一類的參數設置有問題，檢查以後發現read和write的thread設置都是4，這和CPU數一致，因此可以斷定這並不是單顆CPU占用過高的 ...
客戶現場反饋，top的檢查結果中，一個CPU的占用一直是100%。實際上現場有4個CPU，而且這個伺服器是mysql專屬伺服器。
我的第一反應是io_thread一類的參數設置有問題，檢查以後發現read和write的thread設置都是4，這和CPU數一致，因此可以斷定這並不是單顆CPU占用過高的問題。
接下來需要確認MySQL究竟有沒有利用到多核CPU，這個時候需要的工具叫做pidstat，命令如下：
pidstat -u -t -p 18158 得到的結果如下圖所示：
可以看出其實mysqld是可以利用到多核CPU的，那麼此時可以得到一個推斷：
某個CPU上做的事情太占資源了
一般這種最占資源的工作一定會在INNODB_TRX里留下一些端倪，因此檢查一下：
反覆的檢查TRX，發現mysql在不停的執行這個SQL，只是where條件里的值發生了變化，至此我可以推斷出業務應該是寫了一個迴圈來遍歷一個list，然後對每個item都執行update操作。
應該是寫了這麼一段代碼在處理問題：
for (item in list) {
update_db(item);
}檢查這個表並沒有索引，給where條件中的列加上索引，再次檢查CPU的占用，發現現在的占用已經降低到了16%左右，雖然還是很高，但是已經實際上解決了該問題。
這裡我有點感慨，DBA並不是你會寫SQL就可以乾的，DBA實際上是運維人員的一種，運維要掌握多少種技能恐怕只有運維小伙伴們清楚，其實技術難度並不比寫Java
代碼低。DBA掌握多少種檢查問題的手段，DBA面對問題時能不能第一時間找準方向，這都是經驗和功力的展現。
