504错误本身不等于慢SQL，但Nginx日志中request_time接近proxy_read_timeout、upstream_response_time为空或极小、同一path高频报错等特征，结合x-request-id下钻应用日志（查JDBC连接、Preparing语句、未提交事务）及数据库SHOW PROCESSLIST/INNODB_TRX等命令，可精准定位慢SQL或长事务。
504 错误本身不等于慢 SQL，但它在 Nginx 日志中留下的“超时痕迹”，是发现后端慢 SQL 的关键入口。排查重点不是找 504 状态码，而是通过日志字段组合、时间关联和行为模式，把网关层现象和数据库执行串起来。
看 Nginx access log 中的超时特征
打开 /var/log/nginx/access.log，筛选出 504 请求后，重点关注三类字段：
- request_time 接近或等于 proxy_read_timeout（比如固定为 60.000、180.000）：说明 Nginx 等到极限才放弃，不是后端拒绝连接（那是 502），也不是客户端断开（那是 499）；
- upstream_response_time 字段为空（“-”）或极小（如 “0.001”）：表示请求压根没拿到完整响应，大概率卡在后端处理中途，而非网络传输失败；
- 同一 path 高频集中报错（如 /api/order/status?orderId=123 在 1 分钟内出现 47 次 504）：提示该接口存在共性瓶颈，很可能触发了某条未优化的 SQL。
用 x-request-id 或时间戳下钻到应用日志
Nginx 日志只是起点，必须跳转到业务服务日志才能看到真实执行链路：
- 从 access log 中提取某个 504 请求的 x-request-id（若已配置）或精确到秒的时间戳 + path；
- 在 Spring Boot 的 application.log 或 Node.js 的 stdout 日志中搜索该 ID 或时间点；
- 如果只看到 “Started GET /api/order/status” 却没有 “Completed” 记录，或耗时显示为 “29.8s”，就说明请求阻塞在中间环节；
- 重点扫描日志中是否出现：JDBC Connection acquired、Preparing: SELECT ... FROM orders WHERE ...、Transaction started、Transaction not committed —— 这些都是慢 SQL 或长事务的典型信号。
查数据库确认活跃慢查询和未提交事务
一旦锁定可疑接口和发生时间段，立刻登录数据库验证：
- MySQL：运行 SHOW PROCESSLIST; 查看状态为 Sending data、Locked、Updating 且 Time 值大于 30 秒的线程；再执行 SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(timediff(now(), trx_started)) > 30; 找出运行超 30 秒的事务；
- PostgreSQL：运行 SELECT * FROM pg_stat_activity WHERE now() - backend_start > interval '30 seconds';，结合 state = 'active' 和 query 字段判断是否正在执行大查询；
- 检查慢查询日志是否开启，并查看最近是否有对应 SQL 出现（例如 MySQL 的 /var/log/mysql/slow.log）。
绕过 Nginx 直连后端做交叉验证
避免被代理层干扰，快速验证问题是否真出在后端：
- 在 Nginx 服务器上执行：curl -w "\n%{time_total}\n" -o /dev/null -s http://10.0.1.10:8080/api/order/status?orderId=123；
- 若返回耗时也接近 60s 或更长，基本可确认是应用或数据库侧问题；
- 对比 Nginx access log 中同请求的 $upstream_response_time 字段（如日志中显示 "0.002 128.456 0.001"），说明后端真实花了 128 秒——这已远超合理范围，必须查 SQL 执行计划或索引缺失情况。
