如何解決MySQL超過(guò)最大連接數(shù)問(wèn)題

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

創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站、北碚網(wǎng)絡(luò)推廣、小程序定制開(kāi)發(fā)、北碚網(wǎng)絡(luò)營(yíng)銷、北碚企業(yè)策劃、北碚品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供北碚建站搭建服務(wù)，24小時(shí)服務(wù)熱線：13518219792，官方網(wǎng)址：chinadenli.net

但是很多時(shí)候真正的問(wèn)題不在這里。

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

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

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

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

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

老大有一句很實(shí)用的話：遇到問(wèn)題先查日志（mysql、php、nginx等）

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

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

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

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

問(wèn)題排查步驟：

1 、查看實(shí)例配置：

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

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

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

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

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

1262

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

3、排查是什么動(dòng)作占用了這些連接:

[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ù)庫(kù)中有長(zhǎng)時(shí)間沒(méi)有執(zhí)行完成的sql，一直占用著連接沒(méi)有釋放，而應(yīng)用的請(qǐng)求一直持續(xù)不斷的涌入數(shù)據(jù)庫(kù)，這個(gè)時(shí)候數(shù)據(jù)庫(kù)的連接很快就被使用完；所以這個(gè)時(shí)候需要排查為什么這些sql 為什么長(zhǎng)時(shí)間沒(méi)有執(zhí)行完畢，是索引沒(méi)有創(chuàng)建好，還是sql執(zhí)行耗時(shí)嚴(yán)重。

第一條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ù)庫(kù)中拉取訂單到自己的業(yè)務(wù)庫(kù)中那個(gè)，但是在orders 表上沒(méi)有g(shù)mt_modified 的索引，導(dǎo)致了全表掃描；（更加詳盡的排查方法可以參考：為什么我的RDS慢了）；

第二條sql：

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

Alter tale order_1 add index ind_order_gmt_create(gmt_create)；

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

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

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

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

這個(gè)數(shù)值對(duì)于并發(fā)連接很多的數(shù)據(jù)庫(kù)應(yīng)用是遠(yuǎn)遠(yuǎn)不夠的，當(dāng)連接請(qǐng)求大于默認(rèn)連接數(shù)后，就會(huì)出現(xiàn)無(wú)法連接數(shù)據(jù)庫(kù)的錯(cuò)誤，因此我們需要把它適當(dāng)調(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ù)庫(kù)賬號(hào)的密碼后可看到

|

max_connections

|

1000

|

其他需注意的：

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

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

txt,2.

txt

100.

txt。

如何輕松解決MYSQL數(shù)據(jù)庫(kù)連接過(guò)多的錯(cuò)誤

1、MySQL數(shù)據(jù)庫(kù)系統(tǒng)允許的最大可連接數(shù)max_connections。這個(gè)參數(shù)是可以設(shè)置的。如果不設(shè)置，默認(rèn)是100。最大是16384。

2、數(shù)據(jù)庫(kù)當(dāng)前的連接線程數(shù)threads_connected。這是動(dòng)態(tài)變化的。

查看max_connections、max_connections的辦法見(jiàn)后。

如果

threads_connected

==

max_connections

時(shí)，數(shù)據(jù)庫(kù)系統(tǒng)就不能提供更多的連接數(shù)了，這時(shí)，如果程序還想新建連接線程，數(shù)據(jù)庫(kù)系統(tǒng)就會(huì)拒絕，如果程序沒(méi)做太多的錯(cuò)誤處理，就會(huì)出現(xiàn)類似強(qiáng)壇的報(bào)錯(cuò)信息。

因?yàn)閯?chuàng)建和銷毀數(shù)據(jù)庫(kù)的連接，都會(huì)消耗系統(tǒng)的資源。而且為了避免在同一時(shí)間同時(shí)打開(kāi)過(guò)多的連接線程，現(xiàn)在編程一般都使用所謂數(shù)據(jù)庫(kù)連接池技術(shù)。

但數(shù)據(jù)庫(kù)連接池技術(shù)，并不能避免程序錯(cuò)誤導(dǎo)致連接資源消耗殆盡。

這種情況通常發(fā)生在程序未能及時(shí)釋放數(shù)據(jù)庫(kù)連接資源或其他原因造成數(shù)據(jù)庫(kù)連接資源不能釋放，但強(qiáng)壇系統(tǒng)估計(jì)不會(huì)發(fā)生這種低級(jí)的編程錯(cuò)誤。

該錯(cuò)誤的簡(jiǎn)便的檢查辦法是，在刷新強(qiáng)壇頁(yè)面時(shí)，不斷監(jiān)視threads_connected的變化。如果max_connections足夠大，而

threads_connected值不斷增加以至達(dá)到max_connections，那么，就應(yīng)該檢查程序了。當(dāng)然，如果采用數(shù)據(jù)庫(kù)連接池技術(shù)，

threads_connected增長(zhǎng)到數(shù)據(jù)庫(kù)連接池的最大連接線程數(shù)時(shí)，就不再增長(zhǎng)了。

從強(qiáng)壇出錯(cuò)的情況看，更大的可能性是數(shù)據(jù)庫(kù)系統(tǒng)沒(méi)能進(jìn)行適當(dāng)?shù)嘏渲谩Ｏ旅嫣岢鲆稽c(diǎn)建議。供參考

讓你們的工程師把MySQL的最大允許連接數(shù)從默認(rèn)的100調(diào)成32000。這就不會(huì)老出現(xiàn)連接過(guò)多的問(wèn)題了。

查看max_connections

進(jìn)入MySQL，用命令：

show

variables

查看數(shù)據(jù)庫(kù)最大可連接數(shù)的變量值：

max_connections

查看threads_connected

進(jìn)入MySQL，用命令：

show

status

查看當(dāng)前活動(dòng)的連接線程變量值：

threads_connected

設(shè)置max_connections

設(shè)置辦法是在my.cnf文件中，添加下面的最后紅色的一行：

[mysqld]

port=3306

#socket=MySQL

skip-l

如何解決MySQL超過(guò)最大連接數(shù)問(wèn)題 max

方法1、mysql中提高max_connections的值。不要太高，依據(jù)你的內(nèi)存而定。一般8G-16G內(nèi)存服務(wù)器500-1000

mysql set GLOBAL max_connections=1000;

方法2、從應(yīng)用層限制連接數(shù)據(jù)庫(kù)的最大連接數(shù)

當(dāng)前題目：mysql連接數(shù)高怎么辦 數(shù)據(jù)庫(kù)連接數(shù)過(guò)高
分享路徑：http://chinadenli.net/article48/hhjchp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)建站、商城網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站維護(hù)、Google、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)