1、優化思路
當我們發現了一個慢SQL的問題的時候,需要做性能優化,一般我們是為了提高SQL查詢更快,一個查詢的流程由下圖的各環節組成,每個環節都會消耗時間,要減少消耗時候需要從各個環節都分析一遍。
2 連接配置優化
第一個環節是客戶端連接到服務端,這塊可能會出現服務端連接數不夠導致應用程序獲取不到連接。
"MySQL error 1040 "Too many connections" 指的是你的數據庫服務器達到了它的最大連接數限制。這通常發生在數據庫服務器同時處理了太多的客戶端連接請求時。
1、服務端:從服務端來說可以增加連接數,如果多個應用或者請求同時訪問數據庫,連接數不夠的時候可以設置連接數更大些。
-- 修改最大連接數,當有多個應用連接的時候
SHOW VARIABLES LIKE 'max_connections';
2、服務端:及時釋放不活動的連接,交互式和非交互式的客戶端默認超時時間都是28800秒,8小時,我們可以把值調小
-- 及時釋放不活動的連接,注意不要釋放連接池還在使用的連接
SHOW VARIABLES LIKE 'wait_timeout';
3、客戶端:減少從服務端獲取的連接數,如果想要不上每一次執行SQL都創建一個新的連接,我們可以使用數據庫連接池,實現連接的復用。比如dbcp、c3p0、阿里Druid、Hikari(springboot 2.x版本默認的連接池)
連接池也不是越大越好,只要維護好一定數量大小的連接池,其他客戶端排隊等待獲取連接就可以了,有的時候連接池越大,效率反而越低。
Druid默認最大連接池大小是8,Hikari默認最大連接池大小是10。
一般建議連接池大小是機器核數乘以2+1,也就是說4核的機器,連接池維護9個連接就夠了,這個公式從一定程度上來說對其他數據庫也是適用的。
每一個連接,服務端都是需要創建一個線程來處理它的,連接數越多,服務端創建的線程數就會越多。創建連接會消耗時間消耗資源;而且在CPU同時執行執行超過核數的線程是通過分配時間片以及上下文切換方式實現的。CPU的核數是有限的,頻繁的上下文切換會造成比較大的開銷。
所以在修改數據庫的配置的時候需要結合部署服務器的配置,比如服務器的CPU、內存、磁盤、網絡。在不同硬件支撐下MySQL的配置也不盡相同。
參數名稱 | 案例值 |