关于mysql: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/ref...

MySQL Calculator