Nginx日志虽不显示SQL，但通过$request_time与$upstream_response_time对比可定位慢请求根源：若二者接近，瓶颈在后端（大概率慢SQL）；若差值大，则问题在网络、客户端或Nginx配置。
直接看 Nginx 日志本身不会显示 SQL 语句，但它能暴露后端慢响应的“痕迹”。真正拖慢请求的往往不是 Nginx，而是它代理转发后、由 PHP/Python/Java 等应用调用数据库执行的慢 SQL。Nginx 日志里的 request_time 和 upstream_response_time 就是关键突破口。
盯住两个时间字段：定位慢在哪一层
Nginx 访问日志中必须包含这两个变量（需自定义 log_format）：
- $request_time：客户端发起请求到 Nginx 完全返回响应的总耗时（单位：秒，精度毫秒）
- $upstream_response_time：Nginx 向后端（如 PHP-FPM、Tomcat）发起请求，到收到完整响应的时间（单位：秒，可多个值用逗号分隔）
对比二者就能快速判断瓶颈位置：
- 如果 $upstream_response_time 接近 $request_time（比如差值＜0.05s），说明耗时主要在后端服务内部——极大概率是慢 SQL 或逻辑卡顿
- 如果 $upstream_response_time 很小（如 0.02s），但 $request_time 很大（如 3.8s），问题可能出在网络传输、客户端弱网、或 Nginx 自身配置（如 large_client_header_buffers 不足导致缓冲等待）
用日志筛选出可疑请求并关联线索
例如，提取所有 upstream 响应超 1.5 秒的请求，并附带 URL 和状态码：
awk '$NF > 1.5 {print $7, $9, $10}' /var/log/nginx/access.log | sort -k2nr | head -20
其中 是 $request（含 method+path）， 是 $upstream_response_time， 是 $status。再进一步可加 $http_x_forwarded_for 或 $http_user_agent 辅助排查是否来自特定爬虫或异常客户端。
重点标记那些：
• 返回 200 却耗时很高（排除错误干扰）
• 路径重复出现（如 /api/user/profile、/search）
• 参数结构相似（如 ?id=123、?id=456）——暗示同一段代码反复执行慢查询
顺藤摸瓜，把 Nginx 日志线索对接到数据库慢日志
一旦锁定高频慢路径，立刻去查对应后端服务的数据库慢查询日志：
- MySQL：确认
slow_query_log=ON，long_query_time=1，然后用mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log找出最耗时的 SQL - PostgreSQL：检查
log_min_duration_statement = 1000（毫秒），日志中搜索duration:字段 - 再用
EXPLAIN ANALYZE执行对应 SQL，看是否走索引、是否回表、是否扫描行数过多
注意比对时间戳：Nginx 日志里某条请求发生在 [10/May/2026:10:22:33，就去数据库慢日志里查那个时刻前后 ±10 秒内的慢 SQL，提高命中率。
建立常态化监控闭环
单次分析只能解决已发生的慢请求。要提前发现潜伏问题，建议：
- 每天定时用脚本统计
upstream_response_time > 1.0的请求数量和 TOP 5 路径，邮件告警 - 在 Grafana + Prometheus 中接入 Nginx 的
nginx_upstream_response_sec指标，设置 P95 上升阈值触发预警 - 对高风险接口（如搜索、报表导出）强制要求添加 trace_id，并透传到应用层与数据库日志，实现全链路追踪
