Too many connections

(連接數(shù)過(guò)多，導(dǎo)致連接不上數(shù)據(jù)庫(kù)，業(yè)務(wù)無(wú)法正常進(jìn)行)

問(wèn)題還原：

mysql> show variables like ‘%max_connection%’;

| Variable_name | Value |

max_connections | 151 |

mysql> set global max_connections=1;Query OK, 0 rows affected (0.00 sec)

[root@node4 ~]# mysql -uzs -p123456 -h 192.168.56.132

ERROR 1040 (00000): Too many connections

解決問(wèn)題的思路：

1、首先先要考慮在我們 MySQL 數(shù)據(jù)庫(kù)參數(shù)文件里面，對(duì)應(yīng)的 max_connections 這個(gè)參數(shù)值是不是設(shè)置的太小了，導(dǎo)致客戶端連接數(shù)超過(guò)了數(shù)據(jù)庫(kù)所承受的最大值。

• 該值默認(rèn)大小是 151，我們可以根據(jù)實(shí)際情況進(jìn)行調(diào)整。

• 對(duì)應(yīng)解決辦法：set global max_connections=500

但這樣調(diào)整會(huì)有隱患，因?yàn)槲覀儫o(wú)法確認(rèn)數(shù)據(jù)庫(kù)是否可以承擔(dān)這么大的連接壓力，就好比原來(lái)一個(gè)人只能吃一個(gè)饅頭，但現(xiàn)在卻非要讓他吃 10 個(gè)，他肯定接受不了。反應(yīng)到服務(wù)器上面，就有可能會(huì)出現(xiàn)宕機(jī)的可能。

所以這又反映出了，我們?cè)谛律暇€一個(gè)業(yè)務(wù)系統(tǒng)的時(shí)候，要做好壓力測(cè)試。保證后期對(duì)數(shù)據(jù)庫(kù)進(jìn)行優(yōu)化調(diào)整。

2、其次可以限制 InnoDB的并發(fā)處理數(shù)量，如果 innodb_thread_concurrency = 0(這種代表不受限制) 可以先改成 16 或是 64 看服務(wù)器壓力。

如果非常大，可以先改的小一點(diǎn)讓服務(wù)器的壓力下來(lái)之后，然后再慢慢增大，根據(jù)自己的業(yè)務(wù)而定，個(gè)人建議可以先調(diào)整為 16 即可。

MySQL 隨著連接數(shù)的增加性能是會(huì)下降的，在 MySQL 5.7 之前都需要讓開發(fā)配合設(shè)置 thread pool，連接復(fù)用。MySQL 5.7 之后數(shù)據(jù)庫(kù)自帶 thread pool 了，連接數(shù)問(wèn)題也得到了相應(yīng)的解決。

另外對(duì)于有的監(jiān)控程序會(huì)讀取 information_schema 下面的表，可以考慮關(guān)閉下面的參數(shù)：

• innodb_stats_on_metadata=0

• set global innodb_stats_on_metadata=0