关于mysql_pconnect 和 mysql_connect的误解

mysql_pconnect VS mysql_connect误解，mysql_pconnect并非想象的会使的系统运行的比mysql_connect高效。

mysql_pconnect — 打开一个到 MySQL 服务器的持久连接
mysql_connect — 打开一个到 MySQL 服务器的连接

resource mysql_pconnect ([ string $server [, string $username [, string $password [, int $client_flags ]]]] );
据说mysql_pconnect的效率比较好，
首先，当连接的时候本函数将先尝试寻找一个在同一个主机上用同样的用户名和密码已经打开的（持久）连接，如果找到，则返回此连接标识而不打开新连接。
其次，当脚本执行完毕后到 SQL 服务器的连接不会被关闭，此连接将保持打开以备以后使用（mysql_close() 不会关闭由 mysql_pconnect() 建立的连接）。
（以上来自PHP手册）
因此，很多人都采用mysql_pconnect作为开启连接的首先项，是否效果真的很好呢？

当[ string $server [, string $username [, string $password [, int $client_flags ]]]]都一致时，不同的客户端将开启不同的连接，这些连接执行完毕后sleep,等待mysql回收或者等待新的“连接会话”请求唤醒。
如图


即使开启连接的参数相同，不同的客户机或不同的浏览器也会开启新的连接，导致sleep线程增加。
当相同的客户机不同的浏览器，也会开启新的连接，导致sleep线程增加。
甚至相同的客户机相同的浏览器，在特殊的请求动作下，也会开启新的连接，导致sleep线程增加。
（以上可以测试，并查看mysql processlist ——show processlist了解）
因此，所谓永久连接是否存在一个会话机制呢（个人能保持疑问）？至少，目前我看来是有的，并非理想的“先尝试寻找一个在同一个主机上用同样的用户名和密码已经打开的（持久）连接”。
在频繁访问时，或许通过mysql_pconnect开启的连接，可以充当数据库连接池功能，但对数据库开销很多，数据库的核心功能是存储数据，不应该涉及业务或系统级别的工作量，反之系统应该分担数据处理数据的部分功能，但过多的sleep占用了mysql的一部分处理时间。个人觉得不好（仅仅是个人觉得）。

如果永久连接的子进程数目超过了设定的数据库连接数限制，系统将会产生一些缺陷。如果数据库的同时连接数限制为 16，而在繁忙会话的情况下，有 17 个线程试图连接，那么有一个线程将无法连接。如果这个时候，在脚本中出现了使得连接无法关闭的错误（例如无限循环），则该数据库的 16 个连接将迅速地受到影响。请查阅使用的数据库的文档，以获取关于如何处理已放弃的及闲置的连接的方法。（来自PHP手册）
resource mysql_connect ([ string $server [, string $username [, string $password [, bool $new_link [, int $client_flags ]]]]] )
其中new_link
如果用同样的参数第二次调用 mysql_connect()，将不会建立新连接，而将返回已经打开的连接标识。参数 new_link 改变此行为并使 mysql_connect() 总是打开新的连接，甚至当 mysql_connect() 曾在前面被用同样的参数调用过。
$client_flags一致。

每个子进程在其生命周期中只做一次连接操作，而非每次在处理一个页面时都要向 SQL 服务器提出连接请求。这也就是说，每个子进程将对服务器建立各自独立的永久连接。例如，如果有 20 个不同的子进程运行某脚本建立了永久的 SQL 服务器永久连接，那么实际上向该 SQL 服务器建立了 20 个不同的永久连接，每个进程占有一个。因此，永久连接是为通常连接建立一对一的分布而设计的。这意味着必须能够保证在将永久连接替换为非永久连接时，脚本的行为不会改变。使用永久连接将（非常）有可能改变脚本的效率，但不改变其行为！ （也是来自PHP手册）

综上，mysql_pconnect并非想象的一定高效率，而是在一对一的情况下保证高效。