PHP高并发优化技巧分享

PHP响应慢的根源往往不在代码语法本身，而在于I/O等待、网络请求超时、数据库索引缺失、PHP-FPM配置失衡以及OPcache未启用或配置过低等隐性瓶颈；本文直击高并发场景下的四大关键优化方向——强制设置HTTP请求超时、精准建立数据库索引、科学调优FPM进程模型、合理配置OPcache内存与缓存策略，并强调用slowlog、EXPLAIN和实时状态监控代替经验猜测，帮你快速定位并解决真实卡点，让PHP应用从“慢得理所当然”变成“快得有据可依”。

PHP脚本执行慢，先看是不是 file_get_contents 或 cURL 卡住了

很多“PHP慢”其实不是PHP本身慢，而是发起外部HTTP请求时没设超时，一卡就是几十秒。比如调用支付回调、短信接口、第三方API，一旦对方响应延迟或挂掉，file_get_contents 默认会等足60秒才报错。

实操建议：

• 所有 file_get_contents 必须配 stream_context_create，显式设 'timeout' => 3（单位秒）
• 改用 cURL 更可控：必须设置 CURLOPT_TIMEOUT（总耗时）和 CURLOPT_CONNECTTIMEOUT（连接阶段）
• 别在主流程里同步调第三方服务——能异步的丢进队列（如 Redis + 后台worker），不能异步的至少加 try/catch 包住并快速失败

数据库查询拖慢响应，重点查 SELECT * 和缺失索引

一个没走索引的 SELECT * 查几万行，再快的服务器也扛不住。特别是带 ORDER BY、LIMIT 却没用上索引排序字段时，MySQL 可能要全表扫描+临时文件排序。

实操建议：

• 开慢查询日志：slow_query_log = ON，long_query_time = 0.5，直接揪出 >500ms 的SQL
• EXPLAIN 每条高频查询：重点看 type 是否为 ALL（全表扫描），key 是否为 NULL
• 避免 SELECT *：只取需要字段；WHERE 条件字段、ORDER BY 字段、JOIN 关联字段，该建联合索引就建，别只建单列

FPM配置不合理，导致高并发下请求排队

默认 pm = dynamic 配置在小内存机器上很容易撑爆，pm.max_children 设太高会OOM，设太低又让请求在FPM队列里干等，request_slowlog_timeout 不开就看不到谁在排队。

实操建议：

• 算清楚可用内存：每个PHP进程约20–40MB（视扩展而定），pm.max_children ≤ 总内存 × 0.7 ÷ 30
• 打开慢日志：request_slowlog_timeout = 1s，配合 slowlog = /var/log/php-fpm-slow.log 定位卡点
• 把 pm.status_path = /status 配上，用 curl http://your.app/status?full 实时看哪些worker在忙、排队几个请求

OPcache没开或配置过保守，每次请求都重编译

没开OPcache时，每个PHP请求都要从磁盘读PHP文件、词法分析、语法分析、生成opcode——这部分开销在代码量大的项目里非常可观。开了但 opcache.memory_consumption 只设8MB，很快满，频繁踢出缓存，等于白开。

实操建议：

• 确认已启用：php -m | grep opcache，且 opcache.enable=1 在 php.ini 中生效
• 基础配置调高：opcache.memory_consumption=128（单位MB），opcache.max_accelerated_files=20000，opcache.revalidate_freq=60
• 上线后别频繁改PHP文件——开发期可设 opcache.validate_timestamps=1，生产环境务必关掉（=0）

真正卡顿往往不在PHP语法多复杂，而在I/O等待、网络阻塞、锁竞争这些隐性环节。盯住日志、开对监控、别信“应该没问题”的直觉——slowlog 和 EXPLAIN 是最不骗人的两个东西。

今天关于《PHP高并发优化技巧分享》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！