在 FPM 模式下是可以使用 MySQL 持久化连接的。
但是没有办法实现连接池的， 因为一个 worker 只能维持一个长连接，无法和别的 worker 共享， 只能通过配置 pm.max_children 来让 FPM 维持的长连接没有那么多不要超过 MySQL 的最大连接数.
不过这是一个危险操作， 因为你也看到了， 我在写这篇文章的过程中在没有手动重启 FPM 进程之前这个长连接是一直保持的，而如果这个 fpm 进程是空闲的， 那么这个连接就是被浪费的。这有可能导致大量无用的连接占用 MySQL 的连接数， 而连接数是有上限的，超过之后就无法再建立新的连接， 导致后续的连接失败。所以必须设置长连接数的上限， 同时保证 worker 空闲一段时间后退出，（使用 pm.max_spare_servers 实现）或者再处理若干次请求之后重新启动（通过 pm.max_requests 实现）， 以保证 MySQL 的正常连接数。
链接：https://hacpai.com/article/1526490593632
PHP就是被设计成每次运行完以后销毁一切状态，任何数据都不会带到下一个执行环境上去的。
所以不可能内置一个全功能的「连接池」，而只能从第三方扩展里实现。
如果你需要全功能连接池技术，那你就不能用PHP而需要用常驻内存型的语言，比如Java，ASPX，Ruby，Python，等等。
由上面的试验也能看到，不管是哪种 PHP 运行模式，都会使 MySQL 产生很多闲置的连接进程，这会占用很多的内存，若配置不当（mysql.max_connections <<< Apache.MaxClients），在小内存的机器上 MySQL 很容易就会崩掉。更有甚者，当你的产品非常多时，每个产品配置了不同的 MySQL 账号密码，持久连接复用的整体效率会直线下降，大量的连接占着茅坑不拉屎，非常容易就会产生 “Too many connections MySQL error” 错误，进一步则 MySQL 崩掉。
引用自：https://iyaozhen.com/php-mysql_pconnect-discuss.html
在上面一点我们已经提到，更多的链接将会导致cpu频繁切换上下文，性能抖动，严重情况时将会全站崩溃。
假设本来我们的服务器配置是可以保证1000个连接同时稳定运行，突然某一时刻有3000个人并发，导致连接不够用，那么是保证原有1000人都正常运行好，还是让这3000人争抢资源最终导致机器响应不了全站崩溃好呢？
连接池的意义此时才得以体现，我们设置连接池的最大数量为机器能承受并且稳定运行的最大数量。
当已经有这么多的数量在服务的时候，后面的请求申请连接资源时需要进行短暂的等待，若时间到了还是没有空余连接提供，则需要熔断服务，返回给客户端失败。
这样子可以保证机器长期稳定服务。若是越来越多的客户端申请不到资源，则需要提高机器配置。（因为我们的连接池最大数量已经是机器的瓶颈，只能通过硬件配置来提升能服务的数量）
引用自：https://www.siammm.cn/archives/42
连接池是可以有效降低MySQL-Server负载的。原理是 连接池使用一个共享资源的模式，如并发100个请求，实际上并不是每个请求的所有时间都在执行SQL查询。这样100个请求，共享20个MySQL连接就可以满足需求了。当一个请求操作完数据库后，开始进入模板渲染等其它逻辑流程，这时就会释放数据库连接给其他的请求使用。
连接池仅在超大型应用中才有价值。普通的应用采用MySQL长连接方案，每个php-fpm创建一个MySQL连接，每台机器开启100个php-fpm进程。如果有10台机器，每台机器并发的请求为100。实际上只需要创建1000个MySQL连接就能满足需求，数据库的压力并不大。即使有100台机器，硬件配置好的存储服务器依然可以承受。
达到数百或者数千台应用服务器时，MySQL服务器就需要维持十万级的连接。这时数据库的压力就会非常大了。连接池技术就可以派上用场了，可以大大降低数据库连接数。
链接：https://www.jianshu.com/p/b51ceffae567