PHP-数据库永久连接

以下为PHP官网上对数据库永久连接做的解释：

    永久的数据库连接是指在脚本结束运行时不关闭的连接。当收到一个永久连接的请求时。PHP 将检查是否已经存在一个（前面已经开启的）相同的永久连接。如果存在，将直接使用这个连接；如果不存在，则建立一个新的连接。所谓“相同”的连接是指用相同的用户名和密码到相同主机的连接。(mysql_close() 不会关闭由 mysql_pconnect() 建立的连接, 只是保持sleep状态, 可以使用show processlist 查看有哪些正在sleep的连接)

    对 web 服务器的工作和分布负载没有完全理解的读者可能会错误地理解永久连接的作用。特别的，永久连接不会在相同的连接上提供建立“用户会话”的能力，也不提供有效建立事务的能力。实际上，从严格意义上来讲，永久连接不会提供任何非永久连接无法提供的特殊功能。

    为什么？

    这和 web 服务器工作的方式有关。web 服务器可以用三种方法来利用 PHP 生成 web 页面。

　　第一种方法是将 PHP 用作一个“外壳”。以这种方法运行，PHP 会为向 web 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束，因此任何在这个线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭。在这种情况下，使用永久连接不会获得任何地改变——因为它们根本不是永久的。

　　第二，也是最常用的方法，是把 PHP 用作多进程 web 服务器的一个模块，这种方法目前只适用于 Apache。对于一个多进程的服务器，其典型特征是有一个父进程和一组子进程协调运行，其中实际生成 web 页面的是子进程。每当客户端向父进程提出请求时，该请求会被传递给还没有被其它的客户端请求占用的子进程。这也就是说当相同的客户端第二次向服务端提出请求时，它将有可能被一个不同的子进程来处理。在开启了一个永久连接后，所有请求 SQL 服务的后继页面都能够重新使用这个已经建立的 SQL Server 连接。

　　最后一种方法是将 PHP 用作多线程 web 服务器的一个插件。目前 PHP 4 已经支持 ISAPI、WSAPI 和 NSAPI（在 Windows 环境下），这些使得 PHP 可以被用作诸如 Netscape FastTrack (iPlanet)、Microsoft's Internet Information Server (IIS) 和 O'Reilly's WebSite Pro 等多线程 web 服务器的插件。永久连接的行为和前面所描述的多过程模型在本质上是相同的。注意 PHP 3 不支持 SAPI。

　　如果永久连接并没有任何附加的功能，那么使用它有什么好处？

　　答案非常简单——效率。当客户端对 SQL 服务器的连接请求非常频繁时，永久连接将更加高效。连接请求频繁的标准取决于很多因素。例如，数据库的种类，数据库服务和 web 服务是否在同一台服务器上，SQL 服务器如何加载负载等。但我们至少知道，当连接请求很频繁时，永久连接将显著的提高效率。它使得每个子进程在其生命周期中只做一次连接操作，而非每次在处理一个页面时都要向 SQL 服务器提出连接请求。这也就是说，每个子进程将对服务器建立各自独立的永久连接。例如，如果有 20 个不同的子进程运行某脚本建立了永久的 SQL 服务器永久连接，那么实际上向该 SQL 服务器建立了 20 个不同的永久连接，每个进程占有一个。

　　注意，如果永久连接的子进程数目超过了设定的数据库连接数限制，系统将会产生一些缺陷。如果数据库的同时连接数限制为 16，而在繁忙会话的情况下，有 17 个线程试图连接，那么有一个线程将无法连接。如果这个时候，在脚本中出现了使得连接无法关闭的错误（例如无限循环），则该数据库的 16 个连接将迅速地受到影响。请查阅使用的数据库的文档，以获取关于如何处理已放弃的及闲置的连接的方法。

Warning

　　在使用永久连接时还有一些特别的问题需要注意。例如在永久连接中使用数据表锁时，如果脚本不管什么原因无法释放该数据表锁，其随后使用相同连接的脚本将会被永久的阻塞，使得需要重新启动 httpd 服务或者数据库服务。另外，在使用事务处理时，如果脚本在事务阻塞产生前结束，则该阻塞也会影响到使用相同连接的下一个脚本。不管在什么情况下，都可以通过使用 register_shutdown_function() 函数来注册一个简单的清理函数来打开数据表锁，或者回滚事务。或者更好的处理方法，是不在使用数据表锁或者事务处理的脚本中使用永久连接，这可以从根本上解决这个问题（当然还可以在其它地方使用永久连接）。

　　以下是一点重要的总结。永久连接是为通常连接建立一对一的分布而设计的。这意味着必须能够保证在将永久连接替换为非永久连接时，脚本的行为不会改变。使用永久连接将（非常）有可能改变脚本的效率，但不改变其行为！

 

一般超过最大连接会报 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个，保留一个连接是留给超级管理员使用的，防止连接占满了不会把管理员也踢出来。很多网站在运行的时候都会出现连接数受限现象，我认为 十之八九并非是网站的真实访问量太大导致连接数超标，更多是因为我们在设计网站程序的时候采用了不合理的设计架构或数据结构引起的。非正常连接超限可能原 因如下（天缘即时归纳未必完整或无错讹仅供参考）：

1. 类似人数、在线时间、浏览数等统计功能与主程序数据库同属一个数据空间时就很容易出现。
2. 复杂的动态页尤其是用户每次浏览都涉及到多数据库或多表操作时候也很容易出现。
3. 还有就是程序设计的不合理（比如复杂运算、等待等操作放置在数据库交互行为中间进行），或者程序存在释放BUG。
4. 计算机硬件配置太低却安装太高版、太高配置的MySQL。
5. 未采用缓存技术。
6. 数据库未经过优化或表格设计及其复杂。

等等一些原因，都会延长数据库的数据交互时间或增加交互次数。所以，如果大家遇到这类问题，首先要考虑程序是否存在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，说不定会有惊喜。

这样永久连接的好处是当有新的请求时就直接返回这个连接，感觉类似于http1.1协议的keep-alive的用法，到底是开个还是关呢还是不关呢，一般 那些专家都告诉你，当用户量不多时，可以打开keep -live 这样可以，在http协议进行打交道时，给用户保持连接。用户第一次打开建立，然后继续浏览时就不需要新开了，提高用户的体验，当用户量比较大的时候，大量的保持连接会给服务器造成很大压力，所以需要找一个平衡点是开到底还是不开。

关于mysql_free_result和mysql_close

之前用mysql的时候一直是在用短链接，调用mysql_store_result获取一次数据之后就直接调用：

mysql_free_result(m_result);
mysql_close(m_Database);

但是有两个问题：

1. 当使用长连接时（即connect之后一直不close），如果最后会调用mysql_close，需不需要每次都调用mysql_free_result呢?
2. 当mysql_close调用之后，m_result的数据是否还可以用。

先说一下结论：

1. 必须每次调用。因为经过测试，每次mysql_store_result的指针都是不同的，可见并不是共享了同一块buf。
2. 还是可以使用。经过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)