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

獲取連接數(shù)

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

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

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

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

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

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

設(shè)置連接數(shù)

臨時(shí)設(shè)置

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

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

[mysqld]
max_connections = 1000

項(xiàng)目中連接池設(shè)置

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

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

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

取個(gè)整, 我們就設(shè)置為 10 吧。你這個(gè)行不行啊？10 也太小了吧！

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

你需要的是一個(gè)小連接池，和一個(gè)等待連接的線程隊(duì)列

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

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

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

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

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

是不是越大約好

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

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

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

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

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

哎呦，有長進(jìn)哦！

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

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

我去！什么鬼？

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

你這也太溜了！

為啥有這種效果?

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

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

一核 CPU同一時(shí)刻只能執(zhí)行一個(gè)線程，然后操作系統(tǒng)切換上下文，CPU 核心快速調(diào)度，執(zhí)行另一個(gè)線程的代碼，不停反復(fù)，給我們?cè)斐闪怂羞M(jìn)程同時(shí)運(yùn)行假象。

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

說到這里，應(yīng)該恍然大悟了 ……

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