Mysql連接數(shù)設置和獲取的方法

獲取連接數(shù)

--- 獲取最大連接數(shù)
SHOW VARIABLES LIKE '%max_connections%'; 

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

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

--- 獲取連接統(tǒng)計 比如歷史最大連接數(shù)以及最大連接時長等
SHOW STATUS LIKE '%Connection%';

mysql> SHOW STATUS LIKE 'Threads%';
+-------------------+-------+
| Variable_name   | Value |
+-------------------+-------+
| Threads_cached  | 58  |
| Threads_connected | 57  |  ---這個數(shù)值指的是打開的連接數(shù)
| Threads_created  | 3676 |
| Threads_running  | 4   |  ---這個數(shù)值指的是激活的連接數(shù)，這個數(shù)值一般遠低于connected數(shù)值
+-------------------+-------+

Threads_connected 跟show processlist結果相同，表示當前連接數(shù)。準確的來說，Threads_running是代表當前并發(fā)數(shù)

設置連接數(shù)

臨時設置

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

永久設置
可以在/etc/my.cnf里面設置數(shù)據(jù)庫的最大連接數(shù)

[mysqld]
max_connections = 1000

項目中連接池設置

下面公式由 PostgreSQL 提供，不過底層原理是不變的，它適用于市面上絕大部分數(shù)據(jù)庫產(chǎn)品。還有，你應該模擬預期的訪問量，并通過下面的公式先設置一個偏合理的值，然后在實際的測試中，通過微調(diào)，來尋找最合適的連接數(shù)大小。

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

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

取個整, 我們就設置為 10 吧。你這個行不行?。?0 也太小了吧！

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

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

假設說你有 10000 個并發(fā)訪問，而你設置了連接池大小為 10000，你怕是石樂志哦。

改成 1000，太高？改成 100？還是太多了。

你僅僅需要一個大小為 10 數(shù)據(jù)庫連接池，然后讓剩下的業(yè)務線程都在隊列里等待就可以了。

連接池中的連接數(shù)量大小應該設置成：數(shù)據(jù)庫能夠有效同時進行的查詢?nèi)蝿諗?shù)（通常情況下來說不會高于 2*CPU核心數(shù)）。

你應該經(jīng)常會看到一些用戶量不是很大的 web 應用中，為應付大約十來個的并發(fā)，卻將數(shù)據(jù)庫連接池設置成 100， 200 的情況。請不要過度配置您的數(shù)據(jù)庫連接池的大小。

是不是越大約好

模擬 9600 個并發(fā)線程來操作數(shù)據(jù)庫，每兩次數(shù)據(jù)庫操作之間 sleep 550ms，注意，視頻中剛開始設置的線程池大小為 2048。

讓我們來看看數(shù)據(jù)庫連接池的大小為 2048 性能測試結果的鬼樣子：

每個請求要在連接池隊列里等待 33ms，獲得連接之后，執(zhí)行SQL需要耗時77ms, CPU 消耗維持在 95% 左右；

接下來，我們將連接池的大小改小點，設置成 1024，其他測試參數(shù)不變，結果咋樣？

“這里，獲取連接等待時長基本不變，但是 SQL 的執(zhí)行耗時降低了！”

哎呦，有長進哦！

接下來，我們再設置小些，連接池的大小降低到 96，并發(fā)數(shù)等其他參數(shù)不變，看看結果如何：

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

我去！什么鬼？

我們沒調(diào)整任何東西，僅僅只是將數(shù)據(jù)庫連接池的大小降低了，這樣，就能把之前平均 100ms 響應時間縮短到了 3ms。吞吐量指數(shù)級上升啊！

你這也太溜了！

為啥有這種效果?

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

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

一核 CPU同一時刻只能執(zhí)行一個線程，然后操作系統(tǒng)切換上下文，CPU 核心快速調(diào)度，執(zhí)行另一個線程的代碼，不停反復，給我們造成了所有進程同時運行假象。

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

說到這里，應該恍然大悟了 ……

以上就是Mysql連接數(shù)設置和獲取的方法的詳細內(nèi)容，更多關于Mysql連接數(shù)設置和獲取的資料請關注腳本之家其它相關文章！