MySQL链接数超过限制的解决方法

做者： 字体：[ 增长 减少] 类型：转载 时间：2011-07-17

最近网站出现 User 数据库名称 has already more than 'max_user_connections' active connections 的报错，网站瘫痪。有必要研究下这个问题。

 

max_user_connections 是 MySQL 用户链接数的最大值设置，整段语句的意思是：服务器的 MySQL 的最大链接数参数设置不足。解决方法：修改 MySQL 安装目录下 my.ini 或者 my.cnf 文件内的 max_user_connections 参数的数值，重启 MySQL 服务器。

可是正常来讲，MySQL默认的100个链接数是 足够的。咱们须要从程序上去考虑。MySQL的默认最大链接数为100（N），实际给普通用户使用只有N-1个，保留一个链接是留给超级管理员使用的，防 止链接占满了不会把管理员也踢出来。不少网站在运行的时候都会出现链接数受限现象，我认为十之八九并不是是网站的真实访问量太大致使链接数超标，更可能是由于 咱们在设计网站程序的时候采用了不合理的设计架构或数据结构引发的。非正常链接超限可能缘由以下（天缘即时概括未必完整或无错讹仅供参考）：

相似人数、在线时间、浏览数等统计功能与主程序数据库同属一个数据空间时就很容易出现。
复杂的动态页尤为是用户每次浏览都涉及到多数据库或多表操做时候也很容易出现。
还有就是程序设计的不合理（好比复杂运算、等待等操做放置在数据库交互行为中间进行），或者程序存在释放BUG。
计算机硬件配置过低却安装过高版、过高配置的MySQL。
未采用缓存技术。
数据库未通过优化或表格设计及其复杂。
等 等一些缘由，都会延长数据库的数据交互时间或增长交互次数。因此，若是你们遇到这类问题，首先要考虑程序是否存在BUG致使链接释放失败，再次就是考虑优 化软硬件。固然修改MySQL链接数也是软件优化的操做方法之一，但愿你们都可以本着学习的态度经过研究一下自身的缘由从而解决这一问题。若是实在是找不 到缘由，那就只好先修改链接数，暂缓定位真实缘由了。

关于PHP的数据库持久链接 mysql_pconnect
PHP程序 员应该都知道链接MySQL数据库可使用mysql_pconnect（永久链接）函数，使用数据库永久链接能够提升效率，可是实际应用中数据库永久连 接每每会致使出现一些问题，一般的表现就是在大访问量的网站上时常发生断断续续的没法链接数据库的状况，出现相似＂Too many connections in ...＂的错误提示信息，从新启动服务器又正常了，但过不了一下子又出现一样的故障。对于这些问题的成因，恐怕就不是每一个人都能说清楚的了，虽然PHP文 档里有一些相关资料，可是解释的并不浅显易懂，这里我厚着脸皮试图作一个简单的讨论，所述观点不见得全都正确，欢迎你们反馈意见。

首先 看看数据库永久链接的定义：永久的数据库链接是指在脚本结束运行时不关闭的链接。当收到一个永久链接的请求时。PHP 将检查是否已经存在一个（前面已经开启的）相同的永久链接。若是存在，将直接使用这个链接；若是不存在，则创建一个新的链接。所谓"相同"的链接是指用相 同的用户名和密码到相同主机的链接。

PHP使用永久链接方式操做MySQL是有前提的：就是PHP必须安装为多线程或多进程Web服务 器的插件或模块。最多见的形式是把PHP用做多进程Apache服务器的一个模块。对于一个多进程的服务器，其典型特征是有一个父进程和一组子进程协调运 行，其中实际生成Web页面的是子进程。每当客户端向父进程提出请求时，该请求会被传递给尚未被其它的客户端请求占用的子进程。这也就是说当相同的客户 端第二次向服务端提出请求时，它将有可能被一个不一样的子进程来处理。在开启了一个永久链接后，全部不一样子进程请求SQL服务的后继页面都可以从新使用这个 已经创建的 SQL服务器链接。它使得每一个子进程在其生命周期中只作一次链接操做，而非每次在处理一个页面时都要向 SQL 服务器提出链接请求。每一个子进程将对服务器创建各自独立的永久链接。PHP自己并无数据库链接池的概念，可是Apache有进程池的概念, 一个Apache子进程结束后会被放回进程池, 这也就使得用mysql_pconnect打开的的那个mysql链接资源能够不被释放，而是依附在相应的Apache子进程上保存到了进程池中。因而在 下一个链接请求时它就能够被复用。一切看起来彷佛都很正常，可是在Apache并发访问量大的时候，若是使用mysql_pconnect，会因为以前的 Apache子进程占用的MySQL链接没有close, 很快使MySQL达到最大链接数，使得以后的请求可能得不到响应。

上面的部分文字是摘抄自PHP文档，看起来可能仍是有些文绉绉的很差理解，那么我就用大白话再举一个例子来讲明问题：

假 设Apache配置最大链接数为1000，MySQL配置最大链接数为100，当Apache服务器接到200个并发访问的时候，其中100个涉及到数据 库访问，剩下的100个不涉及数据库访问，由于这个时候还不存在可用的数据库链接，因此这里面涉及到数据库访问的100个并发会同时产生100个数据库永 久链接，达到了数据库最大链接数，当这些操做没有结束的时候，任何其余的链接都没法再得到数据库链接，当这些操做结束了，相应的链接会被放入进程池，此时 Apache的进程池里就有了200个空闲的子进程，其中100个是带有数据库链接的，因为Apache会为访问请求随机的挑选空闲子进程，因此你获得的 子进程极可能是不包含数据库链接的那100个中的一个，而数据库链接已经达到了最大值，你也不可能成功的创建新的数据库链接，唉，你便只好不停的刷新页 面，哪一个时候运气好，碰巧分配到了带有数据库链接的子进程，才能正常浏览页面。若是是大访问量的网站来讲，任什么时候候均可能存在大量的并发，因此浏览者可能 就会不停的发现没法链接数据库的现象了。

或许你会说，咱们把Apache和MySQL的最大链接数调成同样大不就能够了么？是的，合理 的调整这个最大链接数某种程度上会避免这个问题的发生，可是Apache和MySQL的负载能力是不一样的，若是按照Apache的负载能力来设置，对于 MySQL来讲，这个最大链接数就偏大，会产生大量的MySQL数据库永久链接，打个比方，就好像和平时代还要养活一个几百万的军队同样，其开销得不偿 失；而若是按照Mysql的负载能力设置，对于Apache来讲，这个最大链接数就偏小，有点杀鸡牛刀的感受，没法发挥Apache的最大效率。

所 以按照PHP手册上的介绍，只适合在并发访问不大的网站上使用数据库永久链接，但对于一个并发访问不大的网站来讲，使用数据库永久链接带来的效率提升彷佛 没有太大的意义，从这个角度上来看，我以为PHP中的数据库永久链接基本上是一个鸡肋的角色，若是你必定要使用数据库链接池的概念，能够尝试一下 sqlrelay或者Apache自己提供的mod_dbd，说不定会有惊喜。

关于mysql_free_result和mysql_close
以前用mysql的时候一直是在用短连接，调用mysql_store_result获取一次数据以后就直接调用：

复制代码 代码以下:

mysql_free_result(m_result);
mysql_close(m_Database);

可是有两个问题：

当使用长链接时（即connect以后一直不close），若是最后会调用mysql_close，需不须要每次都调用mysql_free_result呢?
当mysql_close调用以后，m_result的数据是否还能够用。
先说一下结论：

必须每次调用。由于通过测试，每次mysql_store_result的指针都是不一样的，可见并非共享了同一块buf。
仍是可使用。通过valgrind扫描，只调用mysql_close的扫描结果是：

复制代码 代码以下:

==9397== 16,468 (88 direct, 16,380 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 5
==9397== at 0x40219B3: malloc (vg_replace_malloc.c:195)
==9397== by 0x8053EA2: my_malloc (in /data/home/dantezhu/appbase/application/platform/openqqcom/share/db_openright/test/test)
==9397== by 0x806D314: mysql_store_result (in /data/home/dantezhu/appbase/application/platform/openqqcom/share/db_openright/test/test)
==9397== by 0x804BB04: CMySQLCppClient::Result(st_mysql_res*&) (mysql_cpp_client.cpp:127)
==9397== by 0x804AB58: CDBOpenRight::GetUinsByApp(unsigned int, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >&) (db_openright.cpp:58)
==9397== by 0x8049F10: main (test.cpp:27)

之后再慢慢研究。。