AWS RDS MySQL执行成功但无响应超时问题排查求助

执行以下MySQL插入语句（针对AWS RDS远程数据库）：

INSERT INTO gps_data_eid_cache (eid, location_id, first_seen, last_seen)
SELECT * FROM (
      SELECT eid,
             location_id,
             MIN(day_epoch)     as first_seen,
             MAX(day_epoch)        as last_seen
      FROM gps_visitation_details gvd
      GROUP BY location_id, eid
    ) as temp_1
    ON DUPLICATE KEY UPDATE last_seen = VALUES(last_seen);

实际执行异常表现：

• 语句能正常完成：通过SSH查看数据库进程列表可确认执行结束，目标表也已成功插入/更新记录
• 客户端（PHPStorm、TablePlus、原生PHP PDO）会挂起2小时后触发超时错误：

Communications link failure The last packet successfully received from the server was 7,200,104 milliseconds ago. The last packet sent successfully to the server was 7,200,104 milliseconds ago.

• 近几周才出现该问题，执行表结构修改（如添加索引）操作时也会触发同样的客户端超时。

1. 数据库端会话与超时配置检查 #

• 查看RDS MySQL的wait_timeout和interactive_timeout参数：执行SHOW VARIABLES LIKE '%timeout%';，确认是否设置为2小时（7200秒）——这会导致无交互的会话被强制断开，客户端收不到完成信号。
• 监控会话状态：执行SHOW PROCESSLIST;或查询information_schema.processlist，确认语句执行期间，数据库是否有向客户端发送心跳包，或是会话已完成但未主动通知客户端。
• 分析RDS资源指标：通过AWS CloudWatch或性能Insights查看实例的CPU、内存、磁盘IO使用率，排查是否因资源瓶颈导致数据库无法及时返回执行状态。

2. 网络链路问题排查 #

• 检查RDS安全组与NACL规则：确认是否存在限制数据库回包的规则，或是中间网关/代理（公司内网网关、AWS Transit Gateway）的空闲连接超时设置为2小时，导致连接被强制断开。
• 测试网络稳定性：用ping或mtr工具测试客户端到RDS实例的网络延迟与丢包率，排查是否存在间歇性网络中断，导致客户端无法接收完成信号。
• 验证TCP keepalive配置：对于长时运行的查询，TCP keepalive可防止中间设备断开空闲连接。可在客户端（如PHP PDO）开启该配置，或检查RDS实例操作系统层面的net.ipv4.tcp_keepalive_time等参数。

3. 查询执行特性与优化 #

• 分析执行计划：执行EXPLAIN FORMAT=JSON加上目标查询，查看是否存在全表扫描、大结果集处理等情况，导致数据库完成数据写入后，在返回状态时出现延迟。
• 检查表锁与索引：确认gps_data_eid_cache上触发ON DUPLICATE KEY的唯一键是否存在；执行SHOW ENGINE INNODB STATUS;查看查询期间是否有长时间的表锁/行锁，导致会话资源无法及时释放。
• 拆分查询测试：将原查询拆分为两步——先把SELECT结果写入临时表，再执行INSERT...ON DUPLICATE KEY，观察客户端是否还会超时，判断是否是子查询处理逻辑导致的问题。

4. 客户端配置调整 #

• 检查客户端超时参数：PHP PDO的PDO::ATTR_TIMEOUT、PDO::MYSQL_ATTR_READ_TIMEOUT，以及GUI工具的连接超时配置，是否设置为2小时？尝试缩短超时时间或调整为无超时，同时确认客户端是否会主动检测连接状态。
• 关闭自动重连功能：部分客户端在连接断开后会自动重连，但此时数据库已完成操作，重连后无法获取之前的执行结果，导致误以为查询未完成。关闭该功能后观察错误信息变化。

内容的提问来源于stack exchange，提问作者James Morey