Ubuntu PHP日志中的慢查询怎么办

Ubuntu PHP慢查询的定位与优化全流程

处理PHP应用性能问题，慢查询往往是头号“嫌犯”。但慢查询这事儿，其实有两副面孔，搞混了就容易白忙活一场。

一 明确慢查询来源与差异

在PHP的语境里，“慢查询”通常指向两个不同层面的日志，它们分工明确：

• PHP-FPM慢请求日志：它记录的是整个HTTP请求在PHP层面执行超时的轨迹。比如，一个请求花了3秒，它会告诉你这3秒里，时间主要耗在了哪个函数调用、哪个文件包含，或者哪个数据库查询上。它的核心价值在于帮你找到“慢的入口”。
• 数据库慢查询日志：这才是传统意义上，数据库自己记录的、执行时间超过阈值的SQL语句。它的任务是帮你定位具体的SQL语法和索引设计问题。

所以，一个完整的排查链路通常是：先用PHP-FPM慢日志锁定是哪个请求、哪个环节慢了；如果问题指向数据库，再深入数据库慢日志，用EXPLAIN等工具揪出具体的SQL和索引症结。二者相辅相成，缺一不可。

二 启用并解读PHP-FPM慢请求日志

要让PHP-FPM开口“说话”，首先得打开它的慢日志开关。

• 编辑FPM池配置：找到你所用PHP版本对应的FPM配置文件，路径类似 /etc/php/8.1/fpm/pool.d/www.conf。关键配置有两项：
  • slowlog = /var/log/php-fpm/www-slow.log （指定日志路径）
  • request_slowlog_timeout = 1s （定义“慢”的阈值，比如1秒）

  这里有个细节：只要request_slowlog_timeout设为非0值，slowlog就必须配置。阈值可以根据业务容忍度灵活调整，0.5秒、1秒或2秒都行。

• 创建日志目录并授权：确保日志目录存在且PHP进程有权限写入。通常命令如下：
  • sudo mkdir -p /var/log/php-fpm
  • sudo chown www-data:www-data /var/log/php-fpm
• 重启生效：执行 sudo systemctl restart php8.1-fpm 让配置生效。
• 解读日志要点：打开慢日志文件，你会看到类似这样的记录：

  首行会标明时间、进程池和脚本路径，例如 script_filename = /var/www/html/index.php。

  接下来的多行就是宝贵的调用栈（stack trace），它会精确地告诉你，时间卡在了哪个函数、哪个文件的哪一行。比如，一行记录显示 session_start() /var/www/html/app/models/User.php:11，那优化重点就很明确了——要么优化这个session_start调用，要么检查User.php第11行附近的逻辑。根据这些热点，优先考虑引入缓存、延迟加载或重构代码。

三 启用并分析数据库慢查询日志

当矛头指向数据库，就该数据库慢查询日志登场了。以MySQL 5.7及以上版本为例。

• 启用慢查询日志
  • 临时开启（用于即时诊断）：在MySQL客户端执行：
    • SET GLOBAL slow_query_log = ON;
    • SET GLOBAL long_query_time = 1; （单位秒）
  • 永久配置（推荐生产环境）：编辑MySQL配置文件（如 /etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]段落下添加：
    • slow_query_log = 1
    • slow_query_log_file = /var/log/mysql/slow.log
    • long_query_time = 1
    • log_queries_not_using_indexes = 1 （可选，但非常有用，能记录未使用索引的查询）

    配置完成后，别忘了重启MySQL服务：sudo systemctl restart mysql。

• 分析工具与用法
  • 自带简易工具：MySQL自带的mysqldumpslow可以快速进行初步分析，例如：
    • mysqldumpslow -s at -t 10 /var/log/mysql/slow.log （按平均查询时间排序，取出最慢的10条）
  • 高级分析利器：更推荐使用功能强大的Percona Toolkit。安装后，用其核心工具pt-query-digest可以生成一份详细的报告：
    • 安装：sudo apt-get install percona-toolkit
    • 分析：pt-query-digest /var/log/mysql/slow.log > slow_report.txt

    这份报告会帮你统计出哪些SQL最耗时、执行频率最高，并给出优化建议样本。

• 用EXPLAIN验证问题SQL：从慢日志或分析报告中找到可疑SQL后，一定要用EXPLAIN命令查看其执行计划。重点关注：
  • type列：如果出现ALL，意味着全表扫描，这是重大警报。
  • key列：如果为NULL，说明查询没有使用索引。
  • rows列：预估扫描的行数，数值过大就需要警惕。

  根据EXPLAIN的结果，有针对性地添加或修改索引、重写SQL语句。

四 常见优化手段与配置建议

定位问题只是第一步，接下来才是重头戏——优化。这里有一份从数据库到PHP的立体优化清单。

• SQL与索引优化（治本之策）
  • 为WHERE、JOIN、ORDER BY、GROUP BY子句中的列建立合适的索引。
  • 尽量避免SELECT *，只查询需要的字段。
  • 减少复杂的子查询，避免在WHERE条件中对列使用函数（这会导致索引失效）。
  • 对于分页查询，务必使用LIMIT。
  • 在查询只需索引字段时，考虑使用覆盖索引，避免回表操作。
• PHP-FPM进程与超时调优
  • 合理配置进程管理模型（如dynamic）及相关参数，以下是一个参考配置：
    • pm = dynamic
    • pm.max_children = 50
    • pm.start_servers = 5
    • pm.min_spare_servers = 5
    • pm.max_spare_servers = 35
    • request_terminate_timeout = 30s （这个值应与你的业务超时策略保持一致）
  • 调优的关键在于结合系统监控（如CPU、内存负载），逐步调整，避免进程数过多导致资源争用，反而降低性能。
• 缓存与执行计划优化
  • 启用OPcache：对于生产环境，这是必选项。它能缓存预编译的字节码，极大减少PHP脚本的编译开销。建议配置如下：
    • [opcache]
    • opcache.enable=1
    • opcache.memory_consumption=128
    • opcache.interned_strings_buffer=8
    • opcache.max_accelerated_files=4000
  • 引入外部缓存：使用Redis或Memcached缓存频繁查询的数据库结果、页面片段或会话数据，直接从内存读取，能显著减轻数据库压力。
• 异步与解耦
  • 将耗时较长的任务（如发送邮件、生成报表、处理图片）从HTTP请求主流程中剥离，放入消息队列（如RabbitMQ、Redis队列），由后台Worker异步处理。这样能立刻释放Web进程，大幅缩短用户请求的响应时间。
• 监控与持续改进
  • 性能优化不是一劳永逸的。借助New Relic、Datadog、Blackfire等APM（应用性能管理）工具，结合PHP-FPM状态页和MySQL慢日志，建立起“监控-分析-优化-验证”的闭环，才能让系统性能持续保持健康。

五 快速排查清单

最后，送你一份可以贴在墙上的快速行动清单，遇到性能问题时按图索骥：

• ✅ 确认PHP-FPM慢日志已开启，阈值设置合理（如1秒），并且日志里能清晰看到导致慢的函数和文件行号。
• ✅ 打开MySQL慢查询日志，先用pt-query-digest或mysqldumpslow找出最耗时的Top N条SQL。
• ✅ 对找出的慢SQL，立即使用EXPLAIN检查其执行计划，重点关注扫描类型和行数。
• ✅ 优化时遵循“二八原则”，优先处理那些“执行频率高且单次耗时也高”的SQL，手段包括添加索引、重写查询、减少返回数据量。
• ✅ 在PHP应用侧，检查并治理“N+1查询”问题（使用预加载或批量查询），对热点数据引入缓存，耗时任务丢进消息队列。
• ✅ 根据服务器资源情况，调整PHP-FPM的进程数量和超时时间，并确保OPcache已开启且配置得当。
• ✅ 建立例行性能巡检机制：每周分析慢日志，观察QPS（每秒查询数）、平均响应时间、错误率等关键指标的变化，验证每次优化的效果，并持续迭代。