PDO和MySQLi均不内置连接池，仅支持持久连接；MySQLi容错性更强、控制更细、可观测性更好，而PDO依赖异常重建且资源释放不可控。
如果您在高并发场景下使用PHP连接MySQL数据库，发现连接建立频繁、资源消耗大或出现“Too many connections”错误，则可能是由于缺乏有效的连接复用机制。以下是PDO与MySQLi在连接池能力方面的对比评测步骤：
一、原生扩展对连接池的支持能力
PDO和MySQLi本身均不内置连接池功能，二者均依赖底层MySQL C API，仅提供持久连接（Persistent Connection）作为轻量级复用手段。该机制通过连接复用避免重复TCP握手与认证开销，但并非真正意义上的连接池——它不具备连接数限制、空闲连接回收、连接健康检测等核心特性。
1、PDO启用持久连接需在DSN中添加PDO::ATTR_PERSISTENT => true参数，并在构造时传入属性数组。
2、MySQLi启用持久连接需调用mysqli_options($link, MYSQLI_OPT_PERSISTENT, true)，或在面向对象方式中使用new mysqli('p:localhost', ...)（主机名前加p:前缀）。
立即学习“PHP免费学习笔记（深入）”；
3、两种方式均要求Web服务器采用进程/线程模型（如PHP-FPM的static模式或Apache prefork），在CGI或serverless环境下持久连接无效。
二、连接复用行为的实际差异
MySQLi的持久连接在连接断开后会自动重连并复用连接资源，而PDO在连接异常后不会自动恢复，必须由开发者捕获PDOException并重建实例；此差异导致MySQLi在连接抖动场景下表现出更强的容错性。
1、MySQLi在执行查询失败后，若底层连接已失效，mysqli_ping()可显式探测并触发重连。
2、PDO无对应内置探测方法，需手动执行SELECT 1或依赖驱动层的PDO::ATTR_ERRMODE设置为PDO::ERRMODE_EXCEPTION后捕获异常再重建连接。
3、两者在连接复用期间共享同一MySQL服务端连接ID，可通过SELECT CONNECTION_ID()验证是否发生复用。
三、与外部连接池中间件的兼容性
当接入ProxySQL、MySQL Router或MaxScale等代理型连接池中间件时，PDO与MySQLi的行为一致，均将其视为普通MySQL服务端。此时连接池逻辑完全由中间件实现，扩展层仅需配置对应代理地址与端口。
1、PDO连接字符串应将host设为ProxySQL监听地址，例如"mysql:host=192.168.1.100;port=6032;dbname=test"。
2、MySQLi连接应使用相同代理地址与端口，例如new mysqli("192.168.1.100", "user", "pass", "test", 6032)。
3、两种扩展均支持中间件返回的路由元数据（如PROXYSQL_LAST_QUERY_TIME），但需通过mysqli_get_client_info()或PDO::getAttribute(PDO::ATTR_CLIENT_VERSION)确认驱动版本兼容性。
四、连接生命周期管理的可控粒度
MySQLi提供更细粒度的连接控制接口，允许在单个请求周期内显式关闭物理连接（mysqli_close()），而PDO的连接销毁依赖PHP垃圾回收机制，无法强制释放底层socket资源。
1、MySQLi可在业务逻辑结束时调用mysqli_close($link)立即释放连接，适用于长生命周期脚本中需精确控制资源的场景。
2、PDO未暴露底层socket句柄，unset($pdo)或作用域结束仅解除PHP变量引用，实际连接可能滞留至脚本终止。
3、在CLI模式下处理大批量数据时，MySQLi可通过循环中主动关闭连接避免文件描述符耗尽，这是PDO无法直接实现的关键操作。
五、错误状态下连接状态的可观测性
MySQLi提供mysqli_thread_id()与mysqli_get_warnings()等函数，可实时获取当前连接线程ID及最近警告信息，便于定位连接池中异常连接；PDO仅能通过PDO::errorCode()和PDO::errorInfo()获取最后一次操作错误，无法反映连接层状态。
1、MySQLi在连接被服务端KILL后，调用mysqli_thread_id()将返回0，可据此判断连接失效。
2、PDO在相同情况下仍可能返回非零连接标识，但后续查询抛出异常，无法提前感知连接中断。
3、使用mysqli_stat()可读取服务端当前连接统计（如Threads_connected），配合监控系统实现连接池水位告警，PDO缺乏等效的运行时状态探针接口。
