Nginx 本身并不直接参与数据库查询，它不会自动记录慢查询日志。但事情没那么绝对——通过分析 Nginx 的请求响应时间，你完全可以反向推断出哪些请求背后可能藏着“拖后腿”的数据库查询。换句话说，虽然 Nginx 不直接告诉你“这条 SQL 很慢”，但它能帮你圈定可疑目标，再结合数据库自身的慢查询日志，问题就清晰了。下面说具体怎么做。
找到 Nginx 配置文件。通常路径是
/etc/nginx/nginx.conf，或者站点配置目录/etc/nginx/sites-a vailable/下的某个文件。这一步很简单，但别漏掉。确保访问日志和错误日志已经开启。在
http、server或location块中，确认有类似这样的配置：access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log;没有的话，加上去，这是基础。
接下来是关键：设置一个你认可的“慢”阈值。比如，你觉得响应时间超过 500ms 就算慢，那就在
server或location块中添加下面两行：proxy_read_timeout 500s; proxy_connect_timeout 500s;注意，这里的单位是秒，所以 500s 实际上是 500 秒——这只是一个示例，实际生产环境阈值通常设在 1-5 秒，甚至更短。你可以根据业务需求调整。（原文中写的是 500s，这里保留原数据，但可以提醒读者注意单位。）
保存配置，然后测试语法并重新加载 Nginx：
sudo nginx -t sudo nginx -s reload没有报错的话，改动就生效了。
现在，去分析访问日志吧。直接用
cat查看：cat /var/log/nginx/access.log不过，日志通常很长，直接看效率太低。
所以，用
awk或grep来过滤。比如，想找出响应时间超过 500ms 的请求，可以这样：awk '$7 > 500' /var/log/nginx/access.log这里的
$7对应 Nginx 访问日志中记录响应时间的字段（默认格式下是第7个字段）。如果日志格式自定义过，字段位置可能不同，需要先确认。筛选出这些慢请求后，逐一排查。慢的原因可能是后端应用处理慢，也可能是数据库查询本身效率低，还可能是网络延迟。你需要结合后端日志和数据库的慢查询日志进一步定位。比如 MySQL 的
slow_query_log，PostgreSQL 的log_min_duration_statement等，都是利器。
最后，必须提醒一点：Nginx 日志只能帮你锁定“嫌疑犯”，但真正的“罪证”还得看数据库自身的慢查询日志。两种方法配合使用，才能精准定位性能瓶颈。
