解决Mysql错误Too many connections的方法

MySQL数据库 Too many connections

出现这种错误明显就是 mysql_connect 之后忘记 mysql_close；

当大量的connect之后，就会出现Too many connections的错误，mysql默认的连接为100个，而什么情况下会出现这种错误呢？

正常的mysql_connect 之后调用 mysql_close()关闭连接

但在连接错误时，会者mysql_real_query()出现错误退出时，可能忘记mysql_close()

所以在程序return 之前一定要判断是否close(),最稳妥的方法就是在写任何函数时都只有一个出口！

还有可以通过修改mysql配置文件来加大允许连接的数量！

有时你的服务器是经常出现这样的错误呢：

错误信息如下：

Can not connect to MySQL server

Error: Too many connections

Errno.: 1040

Similar error report has beed dispatched to administrator before.

从官方文档知道Linux上面编译安装的mysql默认的连接为100个

文档：http://dev.mysql.com/doc/refman/5.0/en/too-many-connections.html

mysql官方告诉我们需要修改max_connections的值,那么我们怎么去修改呢？有两种方法

1、修改配置文件文件

修改/etc/my.cnf这个文件，在[mysqld] 中新增max_connections=N，如果你没有这个文件请从编译源码中的support-files文件夹中复制你所需要的*.cnf文件为到 /etc/my.cnf。我使用的是my-medium.cnf,中型服务器配置。例如我的[mysqld]的内容如下

[mysqld]

port = 3306

socket = /tmp/mysql.sock

skip-locking

key_buffer = 160M

max_allowed_packet = 1M

table_cache = 64

sort_buffer_size = 512K

net_buffer_length = 8K

read_buffer_size = 256K

read_rnd_buffer_size = 512K

myisam_sort_buffer_size = 8M

max_connections=1000

由于对mysql还不是很熟悉，所以很多参数没有修改。哈哈。。

2、非使用mysqld脚本自动启动的用户。

修改MYSQLHOME/bin/mysqldsafe文件例如：/usr/local/mysql/bin/mysqldsafe这个文件grep−n‘maxconnection′

MYSQLHOME/bin/mysqldsafe文件例如：/usr/local/mysql/bin/mysqldsafe这个文件grep−n‘maxconnection′MYSQL_HOME/bin/mysqld_safe

修改对应行号的max_connections参数值

3、服务器登录mysql ： mysql -u root -p

百分之九十进不去，进不去的执行重启命令 ：/etc/init.d/mysql restart（centos系统）

此时重启mysql就能连接mysql了，如果还有时间，可以继续下一步，治病要治本

打开配置文件 添加一下配置 vi /etc/my.cnf

wait_timeout = 600

interactive_timeout = 600

再次重启mysql即可

原理解答

mysql 默认100 连接数，超过则连不上，实际工作的连接数远远没有100，大部分在sleep

所以要么增大连接数，要么杀掉无用连接，推荐后者。

遇到mysql超出最大连接数，相信不少人第一反应就是查看mysql进程，看有没有慢查询，当然这个做法是完全正确的！

但是很多时候真正的问题不在这里。

今天有遇到同样的问题，一味查看mysql进程和慢查询日志，无果。

后来老大提点了一下，查看一下nginx日志，发现有一两个访问执行时候比较长，然后使用top命令查看了一下服务器负载，惊了，居然超高！

最后发现原来有一台web分流主机挂了，导致另外几台web主机负载增高，从而导致了php-fpm的执行效率降低。

那么这跟mysql有什么关系呢？原因很简单，因为php执行时间过长，mysql连接迟迟未释放，就会导致连接数过多出现。

最后总结：其实很多时候，一个问题的根本原因并不是那么直接的呈现出来，需要自己去跟踪。

老大有一句很实用的话：遇到问题先查日志（mysql、php、nginx等）

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

排查连接数过多的方法

当用户收到链接数告警时，意味着连接数即将达到该实例的上限。如果实例的连接数超过了实例规定的连接数，将无法创建新的连接，这个时候会影响用户的业务；

Mysql 的连接通常是一个请求占用一个连接，如果该请求（update，insert，delete，select）长时间没有执行完毕，则会造成连接的堆积，迅速的消耗完数据库的连接数，这个时候技术支持人员就要登录数据库进行排序，看看到底是那些sql 占用了连接；

问题排查步骤：

1 、查看实例配置：

可登录RDS控制台“详情与配置”查看实例额定链接数，我们假设最高支持1500个链接

2、 查看当前的连接数：

1）可登录RDS控制台“性能监控”查看实例当前链接数。

2）或者登录数据库查询当前连接，可以使用同步账号或者用户的业务账号登录数据库，执行show processlist；

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

1262

可以看到该实例已经有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、分析连接占用的原因：

可以看到数据库中有长时间没有执行完成的sql，一直占用着连接没有释放，而应用的请求一直持续不断的涌入数据库，这个时候数据库的连接很快就被使用完；所以这个时候需要排查为什么这些sql 为什么长时间没有执行完毕，是索引没有创建好，还是sql执行耗时严重。

第一条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 数据库中拉取订单到自己的业务库中那个，但是在orders 表上没有gmt_modified 的索引，导致了全表扫描；（更加详尽的排查方法可以参考：为什么我的RDS慢了）；

第二条sql：

看到这条sql 正在进行sorting 排序，为什么导致sql 长时间sorting，通常情况下为排序的结果集太大导致排序不能在内存中完成，需要到磁盘上排序，进而导致了性能的下降；解决的办法就是降低排序的结果集，常用的手段是利用索引的有序性，消除排序，或者建立适当的索引减小结果集；我们可以看到第二条sql 的排序字段非常的复杂，但是我们可以看到查询的时间范围是很短，只有5 分钟的时间间隔，这个时候就可以在gmt_create上创建一个索引，过滤掉大部分的记录：

Alter tale order_1 add index ind_order_gmt_create(gmt_create)；

（该用户对orders 进行了分表，大概有50 多张分表需要添加gmt_create 字段的索引）；

5、经过上面两步的优化后，用户实例恢复正常：io 情况和connection 情况，可再次登录RDS控制台查看连接数。

---