mysql启动时间过长失败_MySQL连接的时候出现“too many connection”错误并且启动时间特别长的解决办法 – 爪哇堂 JavaTang...

昨天一台服务器上出现了一个奇怪的问题，正常访问的时候MySQL出现 "error 1040, too many connection" 错误提示，造成这个原因通常是max_connections设置的太小或者wait_timeout的值设置的太长造成连接超时时间太长。所以首先想到的是使用mysqladmin查看max_connections的值为多少

[root@localhost bin]$ ./mysqladmin -uroot -p variables | grep "max_conn"

输入数据库的密码之后就可以看到max_connections的值，如果太小的话(默认为100)需要将该值设置的大一些。如果MySQL不允许中断的话可以登录MySQL之后，然后设置当前max_connections的值

[root@localhost bin]$ ./mysql -uroot -p

mysql> set GLOBAL max_connections=1024;

这里还需要注意的是Linux下如果系统的max user processes低于max_connections的值会出现“Can't create a new thread (errno 11); ”错误，解决方法可以参考MySQL出现Can't create a new thread (errno 11); 的解决办法。上面的设置只是在当前运行的状态下有效，如果mysql重启之后设置失效了，所以终极的方法是修改mysql的配置文件my.cnf，然后在[mysqld]下面设置max_connections的值。

但是奇怪的是这样设置之后还是依然出现那个错误，于是登录mysql之后使用 show processlist; 命令查看连接，然后使用kill命令删除了一些Sleep状态的连接，但是过一会儿又会出现too many connection的错误提示。另外我还注意到一个现象，就是MySQL启动或重启的时候时间特别长，数据库大概有2G左右的数据，但是也不至于启动这么慢吧？后来想到是不是数据库文件有问题，于是又使用了修复命令对每个表进行了修复，但是过一两个小时之后还是会出现上面的错误。

正在一筹莫展的时候，突然想到会不会是硬盘分区被占满了？于是使用 dmidecode -t memory 命令，发现果然数据库所在的分区可用空间为0，原来是因为Nginx的日志文件累加了很长时间把磁盘给塞满了，于是将日志文件删除之后在重启MySQL之后就正常了。