Mysql連接數設置和獲取的方法

獲取連接數

--- 獲取最大連接數
SHOW VARIABLES LIKE '%max_connections%'; 

--- 獲取連接列表
SHOW PROCESSLIST; 
--- 獲取連接列表
SHOW FULL PROCESSLIST; 

--- 獲取當前的鏈接信息 Threads_connected是當前的連接數
SHOW STATUS LIKE 'Threads%';

--- 獲取連接統計 比如歷史最大連接數以及最大連接時長等
SHOW STATUS LIKE '%Connection%';
mysql> SHOW STATUS LIKE 'Threads%';
+-------------------+-------+
| Variable_name   | Value |
+-------------------+-------+
| Threads_cached  | 58  |
| Threads_connected | 57  |  ---這個數值指的是打開的連接數
| Threads_created  | 3676 |
| Threads_running  | 4   |  ---這個數值指的是激活的連接數,這個數值一般遠低於connected數值
+-------------------+-------+

Threads_connected 跟show processlist結果相同,表示當前連接數。準確的來說,Threads_running是代表當前並發數

設置連接數

臨時設置

mysql>show variables like 'max_connections'; --- 查可以看當前的最大連接數
msyql>set global max_connections=1000; --- 設置最大連接數為1000,可以再次查看是否設置成功
mysql>exit --- 退出

永久設置
可以在/etc/my.cnf裡面設置數據庫的最大連接數

[mysqld]
max_connections = 1000

項目中連接池設置

下面公式由 PostgreSQL 提供,不過底層原理是不變的,它適用於市面上絕大部分數據庫產品。還有,你應該模擬預期的訪問量,並通過下面的公式先設置一個偏合理的值,然後在實際的測試中,通過微調,來尋找最合適的連接數大小。

連接數 = ((核心數 * 2) + 有效磁盤數)

核心數不應包含超線程(hyper thread),即使打開瞭超線程也是如此,如果熱點數據全被緩存瞭,那麼有效磁盤數實際是0,隨著緩存命中率的下降,有效磁盤數也逐漸趨近於實際的磁盤數。另外需要註意,這一公式作用於SSD 的效果如何,尚未明瞭。
好瞭,按照這個公式,如果說你的服務器 CPU 是 4核 i7 的,連接池大小應該為 ((4*2)+1)=9。

取個整, 我們就設置為 10 吧。你這個行不行啊?10 也太小瞭吧!

你要是覺得不太行的話,可以跑個性能測試看看,我們可以保證,它能輕松支撐 3000 用戶以 6000 TPS 的速率並發執行簡單查詢的場景。你還可以將連接池大小超過 10,那時,你會看到響應時長開始增加,TPS 開始下降。

你需要的是一個小連接池,和一個等待連接的線程隊列

假設說你有 10000 個並發訪問,而你設置瞭連接池大小為 10000,你怕是石樂志哦。

改成 1000,太高?改成 100?還是太多瞭。

你僅僅需要一個大小為 10 數據庫連接池,然後讓剩下的業務線程都在隊列裡等待就可以瞭。

連接池中的連接數量大小應該設置成:數據庫能夠有效同時進行的查詢任務數(通常情況下來說不會高於 2*CPU核心數)。

你應該經常會看到一些用戶量不是很大的 web 應用中,為應付大約十來個的並發,卻將數據庫連接池設置成 100, 200 的情況。請不要過度配置您的數據庫連接池的大小。

是不是越大約好

模擬 9600 個並發線程來操作數據庫,每兩次數據庫操作之間 sleep 550ms,註意,視頻中剛開始設置的線程池大小為 2048。

讓我們來看看數據庫連接池的大小為 2048 性能測試結果的鬼樣子:

每個請求要在連接池隊列裡等待 33ms,獲得連接之後,執行SQL需要耗時77ms, CPU 消耗維持在 95% 左右;

接下來,我們將連接池的大小改小點,設置成 1024,其他測試參數不變,結果咋樣?

“這裡,獲取連接等待時長基本不變,但是 SQL 的執行耗時降低瞭!”

哎呦,有長進哦!

接下來,我們再設置小些,連接池的大小降低到 96,並發數等其他參數不變,看看結果如何:

每個請求在連接池隊列中的平均等待時間為 1ms, SQL 執行耗時為 2ms.

我去!什麼鬼?

我們沒調整任何東西,僅僅隻是將數據庫連接池的大小降低瞭,這樣,就能把之前平均 100ms 響應時間縮短到瞭 3ms。吞吐量指數級上升啊!

你這也太溜瞭!

為啥有這種效果?

我們不妨想一下,為啥 Nginx 內部僅僅使用瞭 4 個線程,其性能就大大超越瞭 100 個進程的 Apache HTTPD 呢?追究其原因的話,回想一下計算機科學的基礎知識,答案其實非常明顯。

要知道,即使是單核 CPU 的計算機也能“同時”運行著數百個線程。但我們其實都知道,這隻不過是操作系統快速切換時間片,跟我們玩的一個小把戲罷瞭。

一核 CPU同一時刻隻能執行一個線程,然後操作系統切換上下文,CPU 核心快速調度,執行另一個線程的代碼,不停反復,給我們造成瞭所有進程同時運行假象。

其實,在一核 CPU 的機器上,順序執行A和B永遠比通過時間分片切換“同時”執行A和B要快,其中原因,學過操作系統這門課程的童鞋應該很清楚。一旦線程的數量超過瞭 CPU 核心的數量,再增加線程數系統就隻會更慢,而不是更快,因為這裡涉及到上下文切換耗費的額外的性能。

說到這裡,應該恍然大悟瞭 ……

以上就是Mysql連接數設置和獲取的方法的詳細內容,更多關於Mysql連接數設置和獲取的資料請關註WalkonNet其它相關文章!

推薦閱讀: