最近对站点进行了一次全面的性能优化，核心思路是将 Redis 从“可选组件”升级为“全站核心”。整个过程不算复杂，但效果显著，在此记录一下。
一、为什么要做这件事？
之前站点虽然也用了 Redis，但主要是作为缓存驱动，每个 PHP-FPM 进程处理完请求都会断开连接，导致大量的 TIME_WAIT 和高频的连接重建。服务器负载不高，但响应延迟一直下不来。
二、做了哪些调整？
1. 连接模式优化
这是最核心的一步。PHP-FPM 模式下，默认的短连接行为是每次请求都新建 Redis 连接。通过调整底层驱动，将连接模式从短连接改为持久连接，每个 FPM 进程复用同一个 Redis 连接。调整后，Redis 服务端的连接数从动态波动稳定在个位数，建连开销几乎降为零。
2. 缓存架构调整
原本 MySQL 查询缓存和 Redis 应用缓存混用，职责不清。这次将 MySQL 侧的查询缓存彻底关闭，把所有缓存职责交给 Redis。MySQL 只负责数据存储，Redis 负责读写加速，分工明确后整体响应更加稳定。
3. PHP 运行环境优化
开启了 OPcache 并调整了内存参数，减少了 PHP 脚本的重复编译开销。同时根据服务器配置（2GB 内存）重新调整了 PHP 进程管理和 MySQL 的 InnoDB 缓冲池大小，确保各组件合理分配内存。
4. MySQL 配置精简
针对 MySQL 8.4 版本，替换了已弃用的日志参数，关闭了非必要功能，只保留慢查询日志用于日常巡检。
三、效果如何？
目前首页响应稳定在 0.05 秒左右，单次请求的 SQL 查询次数控制在个位数。最直观的感受是页面拖拽感消失，即便在高峰时段也很流畅。
四、一点心得
-
PHP-FPM + Redis 长连接是绝配：参数只是多一个字母
p，效果天差地别。 -
MySQL 查询缓存可以直接关掉：在应用层缓存面前，MySQL 自带的查询缓存收益很低，关了反而省心。
-
2GB 服务器能做的事比想象中多：关键在于把内存分给最需要的组件，不浪费在任何多余的地方。
优化没有终点，但每一次调整都让站点更轻快一些。以上是整个过程的简单记录，供参考。
