Linux中php-fpm与MySQL的连接优化

Linux下 PHP-FPM 与 MySQL 连接优化

一 架构与容量规划

• 明确并发模型：FPM 是多进程模型，每个 worker 在同一进程生命周期内可复用连接，启用持久连接后形成“每个 worker 一个长连接”的伪连接池；这不是真正的连接池，需配合超时与回收策略使用。PHP 本身不提供原生连接池，若需高并发与连接复用，可在常驻内存框架（如 Swoole/Workerman）中实现协程连接池。
• 设定上限与边界：MySQL 的 max_connections 必须大于等于所有上游（FPM workers、后台任务、管理连接等）的峰值并发；FPM 的 pm.max_children 与 MySQL 的 max_connections 需协同设计，避免“连接爆炸”或“连接不够”。
• 连接生命周期：合理设置 wait_timeout / interactive_timeout，避免空闲连接长期占用；FPM 侧通过 pm.max_requests 定期回收进程，清理可能残留的会话状态（事务、临时表、会话变量等）。

二 PHP-FPM 关键配置

• 进程管理策略：优先使用 dynamic，按内存与负载设置 pm.max_children、pm.start_servers、pm.min_spare_servers、pm.max_spare_servers；内存估算可参考“每个 worker 内存 × max_children + MySQL 缓冲等”，避免 OOM。
• 运行时资源：适度提升 memory_limit（如 128M–256M），并启用 OPcache 减少脚本编译开销（示例：opcache.enable=1；opcache.memory_consumption=128；opcache.interned_strings_buffer=8；opcache.max_accelerated_files=4000；opcache.revalidate_freq=60）。
• 连接策略：在 FPM 场景可使用持久连接降低握手成本，但务必控制总量并妥善处理事务/会话状态；若追求更高并发与连接复用，考虑将接口迁移至 Swoole 等常驻内存方案以获得真正的连接池能力。

三 MySQL 服务端配置

• 内存与缓冲：将 innodb_buffer_pool_size 设为服务器总内存的50%–75%（写多场景可略低，读多可偏高），显著提升热点数据与索引的命中率。
• 连接与会话：根据并发设定 max_connections（常见 500–2000 范围需结合实例规格与压测确定）；设置 wait_timeout / interactive_timeout（如 300 s 左右）回收空闲连接，避免连接堆积。
• 日志与诊断：开启 slow_query_log = 1、设置 long_query_time = 2，定位并优化慢 SQL；必要时调整 innodb_log_file_size / innodb_log_buffer_size 提升事务吞吐（配合监控与重启策略）。
• 查询缓存提示：在 MySQL 8.0+ 查询缓存已移除；在 5.7 及更早版本可根据读写特征谨慎启用（高写入场景收益有限甚至下降）。

四 连接策略与代码实践

• 持久连接的正确开启：
  • MySQLi：使用主机前缀 p:，如 new mysqli(‘p:localhost’, ‘u’, ‘p’, ‘db’);
  • PDO：使用属性 PDO::ATTR_PERSISTENT => true。
    持久连接由进程/进程池缓存，能减少 TCP/握手/鉴权开销，但需防止连接数超限与状态污染。
• 事务与会话隔离：持久连接可能跨请求复用，务必在每次请求开始时显式管理事务（如关闭未提交事务）、避免临时表/会话变量跨请求残留；必要时在请求结束处做清理或利用 pm.max_requests 回收进程。
• 真正的连接池：若业务为高并发/低延迟接口，建议采用 Swoole 协程 + 连接池（Channel/Pool 管理连接复用），可显著降低连接建立成本并提升吞吐。

五 监控与压测闭环

• 关键指标与 SQL：
  • 连接维度：MySQL 执行 SHOW STATUS LIKE ‘Threads_connected’; 观察当前连接数；结合 max_connections 评估余量。
  • 慢查询：通过 slow_query_log / long_query_time 捕获劣化 SQL，配合索引与语句改写优化。
  • 系统维度：使用 top/htop、iostat、vmstat 观察 CPU、内存、I/O 与负载，联动调整 FPM 与 MySQL 参数。
  • PHP 层：开启 OPcache 并监控脚本缓存命中率与执行时间分布。
• 变更与回归：任何参数调整先在测试环境验证，逐步滚动变更，持续压测与 A/B 对比，确保稳定性与收益。