Nginx 慢日志调优：如何利用 $request_uri 与 $request_time 筛选定位执行效率最低的慢 API 路径

要精准定位执行效率最低的慢 API 路径，需聚焦“高频 + 高耗时”的动态接口路径，通过日志中 $request_uri 和 $request_time 字段聚类统计平均耗时与调用频次，过滤静态资源后识别共性瓶颈，再结合参数模式与 upstream 响应时间交叉验证真实慢因。

要精准定位执行效率最低的慢 API 路径，核心不是单看某个请求多慢，而是找出“高频 + 高耗时”的接口路径——这类路径往往暴露了后端代码或 SQL 的结构性性能缺陷。

确保日志格式支持深度筛选

必须在 log_format 中同时包含 $request_uri 和 $request_time，且建议把 $request_time 放在末尾便于用 $NF 引用。示例配置：

log_format api_perf '$remote_addr [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_uri $request_time';

同时过滤掉静态资源（如 .js、.css、/images/），专注动态接口路径，避免干扰。

按路径聚类统计平均耗时与出现频次

一条命令即可识别“又慢又常被调用”的问题路径：

• 提取所有耗时 ≥ 800ms 的请求 URI，并统计平均耗时：
  awk '$NF >= 0.8 && $7 !~ /.(js|css|png|jpg|gif)$/ && $7 ~ /^/api// {sum[$7] += $NF; cnt[$7]++;} END {for (uri in sum) print sum[uri]/cnt[uri], cnt[uri], uri}' access.log | sort -k1nr | head -10
• 重点关注平均耗时高 且 出现次数多的路径，例如 /api/order/list 平均 1.6s、出现 247 次，比单次 3.2s 但只出现 2 次的路径更值得优先优化
• 若某路径占全部高耗时请求的 50% 以上，基本可判定其对应服务存在共性瓶颈（如未加索引的查询、N+1 查询、同步远程调用）

结合参数模式识别慢查询共性

相同路径不同参数持续慢，说明问题不在个别数据，而在 SQL 执行计划本身：

• 对目标路径（如 /api/search）提取参数部分：
  awk '$7 ~ /^/api/search/ && $NF >= 0.8 {match($7, /q=[^&]+&page=[^&]+/); if (RSTART) print substr($7, RSTART, RLENGTH)}' access.log | sort | uniq -c | sort -nr
• 观察是否多个不同 q=xxx&page=1 都慢 → 暗示全文检索未走索引、或分页偏移量过大触发全表扫描
• 若仅特定参数组合慢（如 user_id=999999），需检查该用户关联数据是否异常膨胀（如订单超 10 万条未分页）

交叉验证锁定真实瓶颈层

$request_time 高不等于后端慢，必须排除 Nginx 或网络干扰：

• 确认日志中是否也记录了 $upstream_response_time；若两者数值接近（差值
• 若 $request_time 高但 $upstream_response_time 很低（如 0.01s），问题可能在客户端上传、SSL 握手、或 Nginx 响应体压缩开销
• 对确认是后端导致的路径，立即查对应服务日志中的 DB 执行耗时，并用该路径典型参数在数据库中执行 EXPLAIN ANALYZE，验证是否走索引、是否回表、是否用到临时表