502和504错误根因不同：502是Nginx未连上后端或收到非法响应，504是连接成功但超时未获响应；慢查询常伪装为502，需通过Nginx日志、应用SQL耗时、数据库线程状态三方面定位，并优先加索引、精简字段、设查询超时来止血。
502 和 504 都是网关层返回的错误，但根因完全不同：502 表示 Nginx 根本没连上后端，或后端返回了非法响应；504 则说明 Nginx 连上了后端，但等太久没收到完整响应。当后端慢查询拖慢整体响应时，实际触发的是 504（超时），但很多情况下它会“伪装”成 502——比如应用在数据库连接池耗尽后直接断开连接，Nginx 日志里就变成 upstream prematurely closed connection，让人误判为服务崩溃。
先确认是不是慢查询惹的祸
别急着调 Nginx 超时参数。先看证据：
- 查 Nginx error.log：如果高频出现
upstream timed out或upstream prematurely closed connection，且时间集中在某几个接口（如商品列表、订单查询），基本锁定后端处理慢 - 查应用日志：找对应时间段内耗时超过 1s 的 SQL 执行记录，特别是带
SELECT ... JOIN ... ORDER BY ... LIMIT的组合查询 - 查数据库：运行
SHOW PROCESSLIST;看是否有长时间Sending data或Sorting result的线程；用SHOW STATUS LIKE 'Threads_running';看并发执行数是否接近 max_connections
从数据库侧快速止血
慢查询不是配置问题，是数据+逻辑问题。优先做三件事：
-
加索引：对 WHERE、ORDER BY、GROUP BY 字段建联合索引，避免全表扫描。例如
WHERE status=1 AND created_at > '2026-09-30' ORDER BY updated_at DESC，适合建(status, created_at, updated_at) - 砍掉 SELECT *：只查前端真正需要的字段，减少网络传输和内存压力
-
加查询超时：在应用层给数据库连接设置 query_timeout（如 MyBatis 的
timeout属性，或 JDBC 的socketTimeout），防止一条慢 SQL 卡死整个连接池
配合 Nginx 做合理兜底
Nginx 不是万能解药，但能避免雪崩。重点调三个参数，按业务节奏设值：
-
proxy_read_timeout 120s;：这是最关键的，它控制 Nginx 等待后端响应的总时长。普通接口设 30s，报表类可放宽到 120s，但绝不建议无限制 -
proxy_connect_timeout 10s;：连接上游的时限，太短容易误判，太长会堆积无效连接 -
proxy_send_timeout 60s;：向上游发请求的时限，适合大 Body 场景，一般保持默认即可
注意：这些只是缓冲，不能替代慢查询优化。调高 timeout 只会让用户多等两分钟，而不是让系统变快。
长期必须加的监控和告警
靠人工查日志永远滞后。上线前就要埋点：
- 数据库侧：开启 slow_query_log，阈值设为 500ms，并对接 Prometheus + Grafana 监控慢查数量/平均耗时
- 应用侧：在 ORM 层统一打点，记录每个 SQL 的执行时间、影响行数、是否走索引，异常时自动上报
- Nginx 侧：用 log_format 记录
$upstream_response_time，再通过 ELK 或 Loki 分析 P95 响应毛刺，关联出问题时段的慢查日志
