504网关超时本身不等于数据库锁表，但当Nginx频繁返回504且日志显示request_time接近proxy_read_timeout、upstream_response_time为空、应用日志中请求“started”无“completed”，并查得数据库存在长事务或锁等待时，可确认数据库锁表是深层根因。
504 网关超时本身不等于数据库锁表，但当 Nginx 频繁返回 504，且日志特征吻合、接口高度集中、后端响应停滞时，数据库长事务或锁表极可能是深层诱因。排查的关键不是“猜”，而是用 Nginx 日志为起点，逐层下钻到数据库真实状态。
看 Nginx 日志锁定“假性健康”的后端
504 出现时，先别急着调大 proxy_read_timeout。打开 /var/log/nginx/error.log，重点找这三类线索：
- upstream timed out：确认是网关等后端超时，而非网络断连或后端宕机
- request_time 接近或等于 proxy_read_timeout（如固定为 60s、180s）：说明请求被完整接收，但后端“卡住”未返回，不是拒绝连接也不是崩溃
- upstream_response_time 为空（“-”）或极小（如 “0.000”）：后端压根没发出有效响应头，大概率阻塞在执行阶段
用 x-request-id 或时间戳关联应用日志
Nginx access.log 中的 x-request-id（或精确到秒的时间+path）是打通链路的钥匙：
- 在 Spring Boot、Node.js 或 PHP 应用日志中搜索该 ID，看是否有“started”但无“completed”记录
- 若耗时接近 Nginx 超时值（如 log 显示处理了 59s），说明请求卡在某步；重点关注含
JDBC、Transaction、Preparing: SELECT/UPDATE的行 - MyBatis 场景下，看到大量
Preparing: ...却没有后续Parameters:或Results:，基本可判定 SQL 执行被挂起
直查数据库确认活跃长事务与锁
一旦锁定可疑接口和发生时间窗口，立刻登录数据库验证：
-
MySQL：
SHOW PROCESSLIST;查看Time值高、State为Sending data、Locked、Updating的线程；再执行：SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 30; -
PostgreSQL：
SELECT pid, now() - backend_start AS duration, state, query FROM pg_stat_activity WHERE now() - backend_start > interval '30 seconds'; - 若发现事务持续数分钟、且
trx_state = RUNNING、trx_operation_state = fetching rows或卡在lock wait，基本坐实锁表或未提交事务占满连接池
验证连接池是否真的耗尽
数据库没报错，不代表连接池健康。需结合应用侧表现交叉验证：
- 应用日志中频繁出现
Connection refused、Cannot get JDBC Connection、HikariCP - Connection is not available - 监控图表中数据库连接数长期打满（如 HikariCP 的
ActiveConnections持续等于maximumPoolSize） - 同一 URL 在 Nginx access.log 中密集出现 504，且
upstream_addr全指向同一个后端实例——说明该实例所有连接都被阻塞，新请求只能排队超时
