一、问题描述

客户在离线开发数据流中，将处理后的数据集回写到自有 MySQL 数据库。该数据流同步数据量较大，单次约 1000 万行以上。实际运行中，小数据量回写任务基本正常，但该大数据量任务多数失败，少数成功。

失败任务的主要报错为：

回写数据失败, No operations allowed after statement closed

从任务配置和运行记录看，节点未开启超时限制，客户侧也反馈运维排查网络侧未发现明确会话超时设置，任务运行期间服务器资源仍有空余。因此本次重点从数据流执行阶段、回写服务日志、JDBC 写入行为和目标 MySQL 响应情况几个方向进行排查。

二、排查过程

首先对比成功和失败任务日志，发现离线开发的数据处理阶段均能正常完成。典型失败任务中，Spark/离线开发计算阶段约 1 分钟即可产出约 1368 万行临时结果，因此可以先排除 BI 计算慢或 Spark 计算失败。

失败集中发生在后续“数据回写”阶段。进一步查看 6 月 23 日全天 writeback 日志后，定位到失败并不是持续慢写到最后，而是在某个 10000 行 JDBC batch 提交后长时间没有返回结果，随后报错失败。

关键样本如下：

正常情况下，每 10000 行 batch 大约 4-6 秒可以完成。也就是说，失败不是每批逐渐变慢，而是某一个 batch 突然长时间无响应，最终触发异常。

三、原因分析

当前证据表明，问题不在 BI/Spark 计算阶段，而在回写 MySQL 的 JDBC 写入链路。

日志中的 JDBC URL 包含：

socketTimeout=7200000

该参数是后端连接器默认生成的 JDBC 参数，含义是单次 socket 读等待 7200 秒，即 2 小时。它不是任务总时长限制。因此，部分成功任务总耗时超过 2 小时并不矛盾：只要单个 JDBC 操作持续有响应，就不会触发该 socketTimeout。

本次失败的共同特征是：某个 executeBatch() 批次提交后，目标端长时间没有返回结果，约 7200 秒后连接或 statement 被关闭，最终上层看到 No operations allowed after statement closed。

另外，本次实际回写链路是单线程 JDBC batch 写入。数据账户中的“最大连接数”主要影响连接池上限或多个任务同时访问数据库时的可用连接数，不会让单个回写任务自动变成并发推送。因此，单纯调大最大连接数对本问题帮助有限。

综合判断：当前问题更符合目标 MySQL、代理或网络链路在某个 batch 写入、commit、锁等待或连接保持阶段长时间未响应，仍需结合MySQL 日志进一步确认。

四、此类问题处理建议

建议数据库侧继续配合排查以下内容：

1. 分析失败时间段 MySQL error log、slow log、general log，以及代理或 LB 日志。
2. 重点检查是否存在连接被关闭、锁等待、长事务、DDL 操作、磁盘 IO、redo/binlog 压力等情况。
3. 对比目标表结构，包括索引、触发器、外键、字符集、表大小和当前行数。
4. 失败窗口内可观察 SHOW PROCESSLIST、information_schema.innodb_trx，确认是否有写入等待或锁等待。
5. 临时规避上，建议按业务日期或分区拆分同步，降低单次全量写入规模。

当前结论不是确认回写 MySQL 一定存在故障，而是从日志证据看，故障点已经收敛到“BI 回写到 MySQL 的 JDBC 写入链路”，且更偏向目标 MySQL、代理或连接链路在单批写入过程中长时间无响应，后续需MYSQL侧跟进并继续排查；