被告知乙個現場的mysql伺服器cpu 100%了需要處理下，然後就接手了。說下處理過程。
是一台windows機器，作業系統server 2008，cpu 4個物理核心，偏少。國際慣例，先檢查各項指標，show engine innodb status 檢視一下庫總體狀態，發現log sequence number - pages flushed up to 差不多500多m，而庫的redo檔案大小是2個512m，問題不大，但是謹慎起見，調到2個2g大小。free buffers/innodb_buffer_pool_pages_free 挺多的，說明設定的記憶體是足夠的；如果這個值偏小，又能看到掛起的非同步io寫的話，說明可能是io能力不足，從記憶體寫出到磁碟的速度趕不上資料變更的速度；也有可能是記憶體偏小，資料不能達到足夠的快取週期，就被交換出去。要具體分析。接著pending normal aio reads: [0, 0, 0, 0] , aio writes: [32, 0, 15, 32]，4個寫執行緒，磁碟寫掛起的挺多的，再往後一看，16w/s的寫入，有點多了，innodb_io_capacity從200調整到2000，innodb_io_capacity_max從2000調整到10000，io寫執行緒數innodb_write_io_threads從4調整到8個。需要說一下的是，這個調整並不必要，雖然掛起的寫比較多，但是free buffer較多，所以只能說明寫入東西比較多而已，磁碟寫出的速度是夠的，我這調整了，只是調到乙個我認為的合理值，免得後面又來煩我。 8g的innodb_buffer_pool_size，innodb_buffer_pool_instances設定為1，有爭用的風險，將innodb_buffer_pool_instances調整到4。performance_schema.threads觀察到有不到10個session處於等待表鎖的狀態，waiting for table level lock，可能是有myisam引擎的表，於是檢視了 '%key%read%'和 '%key%write%狀態變數，發現key cache命中率偏低，只有98%不到，於是又增大了key_buffer_size。接著又看到了innodb_log_buffer_size=1m，順手調整到16m。
截至到這裡，都是一些目力所及能發現的問題，就直接調整了。然並卵，cpu並沒有降下來，說明這些並不是cpu高的主因。繼續。
這裡顯式的tid在mysql中對應threads表的thread_os_id列。那麼根據這裡的id，然後去mysql裡檢視threads就可以了。有乙個問題是，這裡看到的cpu消耗高的執行緒是不斷變化的，有可能我們把這裡的tid拿到mysql資料庫中去查的時候，執行緒已經把活幹完了，那我們就什麼都看不到了。別急，mysql很貼心的，performance_schema.events_statements_history儲存了單個執行緒最近執行的若干條sql，從這裡面能看到過去都幹了些啥，執行緒都執行了哪些sql。events_statements_history中預設儲存了每個執行緒最近10條sql，受引數performance_schema_events_statements_history_size控制。我們可以把這個引數設大一點，那就能追溯更多的執行歷史。
另外乙個問題是，如果sql長度過長，我們從mysql表或者檢視中並不能抓取到完整的sql，這時候，performance_schema_max_sql_text_length引數就makes difference了。performance_schema_max_sql_text_length控制了mysql表中儲存的sql的長度，預設是1024位元組，超過這個長度會被截斷儲存。最大可以調整到1048576也就是1m大小。
下面這個是我用來找問題sql的sql，貢獻出來，希望對您有用。
set @v_thread_id= 4660 ;
select * from (
select b.`thread_os_id`,b.`name`,a.`event_name`,a.`timer_wait`,a.`lock_time`,a.`sql_text`,a.`digest`,a.`object_type`,a.`object_name`,a.`rows_sent`,
a.`rows_examined`,a.`created_tmp_disk_tables`,a.`select_full_join`,a.`select_scan`,a.`sort_rows`,a.`sort_merge_passes`,a.`no_index_used`
from events_statements_history a,threads b
where a.`thread_id` =b.`thread_id`
and b.`thread_os_id` in (@v_thread_id)
union all
select b.`thread_os_id`,b.`name`,a.`event_name`,a.`timer_wait`,a.`lock_time`,a.`sql_text`,a.`digest`,a.`object_type`,a.`object_name`,a.`rows_sent`,
a.`rows_examined`,a.`created_tmp_disk_tables`,a.`select_full_join`,a.`select_scan`,a.`sort_rows`,a.`sort_merge_passes`,a.`no_index_used`
from events_statements_current a,threads b where a.thread_id=b.`thread_id` and b.`thread_os_id` in (@v_thread_id)
)t order by `timer_wait` desc;
mysql cpu使用高案例處理
今天得監控總是在報警，cpu使用高，登入到伺服器上看了下使用者cpu確實挺高，登入到mysql中看了下，沒什麼高的併發使用者，也沒有什麼慢的sql，拿到一條頻繁執行的sql看了下，40多萬的記錄，全表掃，雖然執行的挺快，但是這種還是挺耗費資源的，就在字段上加了索引，但是這個欄位是longtext，只...
Mysql CPU占用高的問題解決方法小結
通過以前對mysql的操作經驗，先將mysql的配置問題排除了，檢視msyql是否執行正常，通過檢視mysql data目錄裡面的 err檔案 將副檔名改為.txt 記事本檢視即可。如果過大不建議用記事本了，容易死掉，可以用editplus等工具 簡單的分為下面幾個步驟來解決這個問題 1 mysql...
MySQL SYS CPU高的案例分析（二）
原文 mysql sys cpu高的案例分析 二 後面又做了補充測試，增加了每秒context switch的監控，以及sql執行時各步驟消耗時間的監控。測試現象一 啟用1000個併發執行緒的壓測程式，保持壓測程式持續執行，保持innodb spin wait delay預設值不變 在10 17 1...