如何修改MySQL連接數(shù)超限的方法

mysql的最大連接數(shù)默認是100,

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、小程序定制開發(fā)、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了仲巴免費建站歡迎大家使用！

這個數(shù)值對于并發(fā)連接很多的數(shù)據(jù)庫應(yīng)用是遠遠不夠的，當連接請求大于默認連接數(shù)后，就會出現(xiàn)無法連接數(shù)據(jù)庫的錯誤，因此我們需要把它適當調(diào)大一些。

調(diào)節(jié)方法為：

1.linux服務(wù)器中

：改my.cnf中的值就行了

2.Windows服務(wù)器中（我用的）:

在文件“my.ini”中找到段

[mysqld],在其中添加一行

max_connections=200###

200可以更改為想設(shè)置成的值.

然后重啟"mysql"服務(wù)。

/mysqladmin所在路徑/mysqladmin

-uroot

-p

variables

輸入root數(shù)據(jù)庫賬號的密碼后可看到

|

max_connections

|

1000

|

其他需注意的：

在編程時，由于用mysql語句調(diào)用數(shù)據(jù)庫時，在每次之執(zhí)行語句前，會做一個臨時的變量用來打開數(shù)據(jù)庫，所以你在使用mysql語句的時候，記得在每次調(diào)用完mysql之后就關(guān)閉mysql臨時變量。

另外對于訪問量大的，可以考慮直接寫到文本中，根據(jù)預(yù)測的訪問量，先定義假若是100個文件文件名依次為1.

txt,2.

txt

100.

txt。

如何修改mysql數(shù)據(jù)庫的連接數(shù)

新安裝后的mysql數(shù)據(jù)庫，其默認的最大連接數(shù)為100。 方法一：在mysql安裝路徑下，找到my.ini或者my.cnf文件，打開它找到max_connections,設(shè)置成1000; 然后重啟mysql服務(wù)。 方法二：在mysql運行環(huán)境下，進入mysql命令下： mysql set global max_connections=1000; 然后關(guān)閉mysql重啟它； 在./bin路徑下，使用 # ./mysqladmin -uroot -p123456 variables | grep "max_connections" 看到 | max_connections | 1000 | 說明新修改的連接數(shù)已經(jīng)生效了。 也可以在mysql運行環(huán)境下，執(zhí)行：mysql show variables; 查看max_connections的值。 也可以在mysql運行環(huán)境下，執(zhí)行：mysql show status; 查看當前活動的連接線程值，即找到threads_connected的值就是了。 方法三：編輯mysqld_safe文件： # vi /usr/local/mysql/bin/mysqld_safe 找到msyqld啟動的那兩行，在后面加上參數(shù)： 然后重新啟動mysql服務(wù)，就OK了。

如何解決MySQL超過最大連接數(shù)問題

遇到mysql超出最大連接數(shù)，相信不少人第一反應(yīng)就是查看mysql進程，看有沒有慢查詢，當然這個做法是完全正確的！

但是很多時候真正的問題不在這里。

今天有遇到同樣的問題，一味查看mysql進程和慢查詢?nèi)罩荆瑹o果。

后來老大提點了一下，查看一下nginx日志，發(fā)現(xiàn)有一兩個訪問執(zhí)行時候比較長，然后使用top命令查看了一下服務(wù)器負載，驚了，居然超高！

最后發(fā)現(xiàn)原來有一臺web分流主機掛了，導(dǎo)致另外幾臺web主機負載增高，從而導(dǎo)致了php-fpm的執(zhí)行效率降低。

那么這跟mysql有什么關(guān)系呢？原因很簡單，因為php執(zhí)行時間過長，mysql連接遲遲未釋放，就會導(dǎo)致連接數(shù)過多出現(xiàn)。

最后總結(jié)：其實很多時候，一個問題的根本原因并不是那么直接的呈現(xiàn)出來，需要自己去跟蹤。

老大有一句很實用的話：遇到問題先查日志（mysql、php、nginx等）

===============================================================

排查連接數(shù)過多的方法

當用戶收到鏈接數(shù)告警時，意味著連接數(shù)即將達到該實例的上限。如果實例的連接數(shù)超過了實例規(guī)定的連接數(shù)，將無法創(chuàng)建新的連接，這個時候會影響用戶的業(yè)務(wù)；

Mysql 的連接通常是一個請求占用一個連接，如果該請求（update，insert，delete，select）長時間沒有執(zhí)行完畢，則會造成連接的堆積，迅速的消耗完數(shù)據(jù)庫的連接數(shù)，這個時候技術(shù)支持人員就要登錄數(shù)據(jù)庫進行排序，看看到底是那些sql 占用了連接；

問題排查步驟：

1 、查看實例配置：

可登錄RDS控制臺“詳情與配置”查看實例額定鏈接數(shù)，我們假設(shè)最高支持1500個鏈接

2、 查看當前的連接數(shù)：

1）可登錄RDS控制臺“性能監(jiān)控”查看實例當前鏈接數(shù)。

2）或者登錄數(shù)據(jù)庫查詢當前連接，可以使用同步賬號或者用戶的業(yè)務(wù)賬號登錄數(shù)據(jù)庫，執(zhí)行show processlist；

[root@r41d05036.xy2.aliyun.com ~]# mysql -uroot -h127.0.0.1 -P3020 -e “show processlist”|wc -l

1262

可以看到該實例已經(jīng)有1262 個連接

3、排查是什么動作占用了這些連接:

[root@r41d05036.xy2.aliyun.com ~]# myql -uroot -h127.0.0.1 -P3018 -e “show full processlist”/tmp/1.log

root@r14d11038.dg.aliyun.com # more /tmp/1.log

615083 my_db 223.4.49.212:54115 my_db Query 100 Sending data

INSERT INTO tmp_orders_modify (oid, tid, seller_id, status, gmt_create, gmt_modified)

SELECT oid, tid, seller_id, status, gmt_create, gmt_modified

FROM sys_info.orders WHERE

gmt_modified NAME_CONST(‘v_last’,_binary’2012-12-24 10:33:00’ COLLATE ‘binary’) AN

D gmt_modified = NAME_CONST(‘v_curr’,_binary’2012-12-24 10:32:00’ COLLATE ‘binary’)

621564 my_db 223.4.49.212:46596 my_db Query 3890 sorting result

insert into tmp_trades(sid, d, h, tc, tm, tp, ic, new_tp, old_tp)

select a.seller_id as sid,

…………..

from orders_1 as a where seller_id =1 and is_detail = ‘1’

and created date_format(‘2012-12-24 10:35:00’, ‘%Y-%m-%d %H:00:00’)

and gmt_create date_format(‘2012-12-24 10:40:00’, ‘%Y-%m-%d %H:%i:00’)

and gmt_create = date_format(‘2012-12-24 10:35:00’, ‘%Y-%m-%d%H:%i:00’)

group by d, h

order by d

……………….此處省略其他sql

4、分析連接占用的原因：

可以看到數(shù)據(jù)庫中有長時間沒有執(zhí)行完成的sql，一直占用著連接沒有釋放，而應(yīng)用的請求一直持續(xù)不斷的涌入數(shù)據(jù)庫，這個時候數(shù)據(jù)庫的連接很快就被使用完；所以這個時候需要排查為什么這些sql 為什么長時間沒有執(zhí)行完畢，是索引沒有創(chuàng)建好，還是sql執(zhí)行耗時嚴重。

第一條sql：

INSERT INTO tmp_orders_modify (oid, tid, seller_id, status, gmt_create, gmt_modified)

SELECT oid, tid, seller_id, status, gmt_create, gmt_modified

FROM sys_info.orders WHERE

gmt_modified NAME_CONST(‘v_last’,_binary’2012-12-24 10:33:00’ COLLATE ‘binary’) AN

D gmt_modified = NAME_CONST(‘v_curr’,_binary’2012-12-24 10:32:00’ COLLATE ‘binary’)

是用戶從sys_info 數(shù)據(jù)庫中拉取訂單到自己的業(yè)務(wù)庫中那個，但是在orders 表上沒有g(shù)mt_modified 的索引，導(dǎo)致了全表掃描；（更加詳盡的排查方法可以參考：為什么我的RDS慢了）；

第二條sql：

看到這條sql 正在進行sorting 排序，為什么導(dǎo)致sql 長時間sorting，通常情況下為排序的結(jié)果集太大導(dǎo)致排序不能在內(nèi)存中完成，需要到磁盤上排序，進而導(dǎo)致了性能的下降；解決的辦法就是降低排序的結(jié)果集，常用的手段是利用索引的有序性，消除排序，或者建立適當?shù)乃饕郎p小結(jié)果集；我們可以看到第二條sql 的排序字段非常的復(fù)雜，但是我們可以看到查詢的時間范圍是很短，只有5 分鐘的時間間隔，這個時候就可以在gmt_create上創(chuàng)建一個索引，過濾掉大部分的記錄：

Alter tale order_1 add index ind_order_gmt_create(gmt_create)；

（該用戶對orders 進行了分表，大概有50 多張分表需要添加gmt_create 字段的索引）；

5、經(jīng)過上面兩步的優(yōu)化后，用戶實例恢復(fù)正常：io 情況和connection 情況，可再次登錄RDS控制臺查看連接數(shù)。