mysql 執行緒池 Mysql 執行緒池

why

在5.6以前，mysql會對每個連線建立乙個執行緒,請求結束後銷毀執行緒。在高併發的情況下，為了避免頻繁建立和釋放連線，可以通過thread-cache將執行緒快取起來，請求來了先嘗試從cache中獲取，重複利用執行緒資源。

問題在低併發的情況下，thread_cache可以成為乙個有效的優化機制，但在併發突然增加時，會產生非常嚴重的問題。比如thead_cache_size是512，突然來了3000個連線怎麼辦？

mysql在5.6之前，會硬著頭皮建立3000個執行緒！如果是一台一般配置的機器，比如32核、128g這種看起來還不錯的配置，會因為執行緒上下文切換，導致整個例項無法及時響應問題，即使按主鍵查詢，也可能超過1s，因此dba可能建議你：控制連線數在300左右。

通過客戶端使用連線池技術，是可以控制總的連線個數，超過連線池最大值，客戶端直接拒絕響應。但隨著機器的擴大，在微服務還未完全的系統中，多個應用連乙個庫並非不可能，再諸如乙個mysql例項多庫的情況，更上雪上加霜。

通過在5.5版本上的遭遇，在3.5k的connections和threads情況下，mysql所在機器的cpu、memory不是效能陡然下降的原因，此時cpu有可能利用率很低，因為時間都花在了切換執行緒上下文上了，作業系統的資源也包括執行緒資源。

當然可以設定 max_connections，在連線過多時，拒絕信的連線請求

解決乙個執行緒可以處理多個連線

連線被thread group管理起來，group的數量和cpu核心數相當，每個group最少有乙個連線，達到最大程度利用cpu的效果，按連線的性質進行重要性排序和queued

適用場景

threads_running變數持續較高，如innodb引擎中，總是超過40

如果你在使用innodb_thread_concurrency來限制同時執行語句的數量，他們解決了相同的問題

主要是短查詢時

較多的事務導致的資源競爭，導致獲取鎖的時間消耗變大，thread pool將減少這樣的競爭

經驗值thread_pool_size ：執行緒組數量，預設16，建議16-36，最好是24-36，值的範圍1-64，否則報錯(執行緒組數量與cpu相當，每個執行緒組中有workerthread,listenthread)

thread_pool_stall_limit：將乙個sql打標成stall的時間的閾值，意思為這個sql占用了較長的時間，該讓個其它人了，較低的值允許執行緒更快的啟動起來；避免死鎖。較高的值適合於長時間執行的語句，避免當前語句執行時有太多其他語句執行

每乙個group有多個worker執行緒，乙個worker執行緒可以處理多個連線的sql，可以按優先順序進行佇列排序，比如預設的按事務排序

show global variables like 『%thread_handling%『;