獲取連接數

--- 獲取最大連接數
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連接數設置和獲取的資料請關注腳本之家其它相關文章！