MySQL ERROR 1040: Too many connections

如題，本章主要講下當服務器出現 ERROR 1040: Too many connections錯誤時的一些處理心得。

max_connections查看

## 查看最大鏈接數
SHOW VARIABLES LIKE "max_connections";
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 512   |
+-----------------+-------+

## 查看已使用最大鏈接數
SHOW VARIABLES LIKE 'Max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 499   |
+----------------------+-------+

　　

處理方案

這個問題通常有兩種處理方案，解決方案很是容易，咱們只須要增長max_connections鏈接數便可。

增長當前會話的mysql最大鏈接數

SET GLOBAL max_connections = 1000;

上面mysql鏈接值臨時增長到1000，但僅適用於當前會話。一旦咱們從新啓動mysql服務或從新啓動系統，該值將重置爲默認值。

永久增長mysql最大鏈接數

爲了永久增長mysql鏈接數，咱們須要編輯mysql配置文件，即/etc/my.cnf。

sudo vim /etc/my.cnf

## 修改
max_connections = 1000

保存文件重啓MySQL便可生效。

擴多少合適？

Max_connextions並非越大越好的，那麼如何配置？

方式一

對於提升MySQL的併發，很大程度取決於內存，官方提供了一個關於innodb的內存計算方式：

innodb_buffer_pool_size
+ key_buffer_size
+ max_connections * (sort_buffer_size + read_buffer_size + binlog_cache_size)
+ max_connections * 2MB

方式二

安裝比例擴容：

max_used_connections / max_connections * 100% = [85, 90]%

最大使用鏈接數/最大鏈接數達到了80%～90%區間，就建議進行優化或者擴容了。

擴展

如下也涉及幾種常見的影響MySQL性能的狀況：

線程

SHOW STATUS LIKE  'Threads%';
+-------------------+--------+
| Variable_name     | Value  |
+-------------------+--------+
| Threads_cached    | 1      | 
| Threads_connected | 217    |
| Threads_created   | 29     |
| Threads_running   | 88     |
+-------------------+--------+

SHOW VARIABLES LIKE 'thread_cache_size';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| thread_cache_size | 10     |
+-------------------+-------+

• Threads_cached 線程在緩存中的數量
• Threads_connected 當前打開的鏈接數
• Threads_created 建立用於處理鏈接的線程數。
• Threads_running 未休眠的線程數

若是Threads_created大，則可能要增長thread_cache_size值。緩存未命中率能夠計算爲Threads_created / Connections

查看錶鎖狀況

SHOW GLOBAL STATUS LIKE 'table_locks%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| Table_locks_immediate | 90    |
| Table_locks_waited    | 0     |
+-----------------------+-------+

• Table_locks_immediate 當即得到表鎖請求的次數
• Table_locks_waited 沒法當即得到對錶鎖的請求的次數，須要等待。這個值太高說明性能可能出現了問題，並影響鏈接的釋放

慢查詢

show variables like '%slow%';

+---------------------------+----------------------------------------------+
| Variable_name             | Value                                        |
+---------------------------+----------------------------------------------+
| slow_launch_time          | 2                                            |
| slow_query_log            | On                                           |
+---------------------------+----------------------------------------------+

 

線程詳情

## 查看每一個線程的詳細信息
SHOW PROCESSLIST;
+--------+----------+------------------+--------------+---------+-------+-------------+------------------+
| Id     | User     | Host             | db           | Command | Time  | State       | Info             |
+--------+----------+------------------+--------------+---------+-------+-------------+------------------+
|      3 | xxxadmin | localhost        | NULL         | Sleep   |     1 | cleaning up | NULL             |
|      4 | xxxadmin | localhost        | NULL         | Sleep   |     0 | cleaning up | NULL             |
|      5 | xxxadmin | localhost        | NULL         | Sleep   |     6 | cleaning up | NULL             |
+--------+----------+------------------+--------------+---------+-------+-------------+------------------+

總結

固然，以上只是一個大概的解決思路，不管使用哪種方式，都須要結合實際業務場景去擴容。

另外，對於生產環境，設置恰當的告警閾值，也是頗有必要的。

最後，在編程時，因爲用MySQL語句調用數據庫執行SQL，會分配一個線程操做MySQL，因此在結束調用後，須要回收鏈接，避免泄漏。

參考文章

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_max_connections

https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html

https://dev.mysql.com/doc/refman/8.0/en/memory-use.html

MySQL Calculator