根本原因是远程tcp连接在执行过程中被意外切断，而非存储过程本身主动中断；具体表现为防火墙空闲超时、云负载均衡断连或网络抖动，触发wait_timeout、net_read_timeout或net_write_timeout等超时机制，导致call执行中途断开并报“mysql server has gone away”。
存储过程执行中断的根本原因不是存储过程本身
MySQL 存储过程本身不会“主动中断”，它只是在当前连接上下文中执行 SQL 语句。真正导致中断的，是底层 TCP 连接在执行过程中被意外切断——而远程连接不稳定（如防火墙空闲超时、云厂商 LB 断连、网络抖动）会让 mysql 连接在 CALL proc_name() 执行中途突然断开，此时过程尚未返回，客户端收不到完整响应，表现为“执行中断”或 MySQL server has gone away 错误。
为什么远程不稳定对存储过程更敏感？
相比单条 SELECT 或 INSERT，存储过程往往：持续时间更长、内部包含多条语句、可能涉及事务控制（BEGIN/COMMIT）、甚至调用循环或游标。这意味着它更容易撞上三类超时边界：
-
wait_timeout：连接空闲超过该值后被 MySQL 主动 kill（常见于过程启动前等待参数或中间暂停） -
net_read_timeout：过程执行中，客户端未及时发后续指令（如 FETCH 游标），MySQL 等待读取超时 -
net_write_timeout：过程执行中，MySQL 向客户端写结果集时卡住（如大结果集 + 网络丢包），触发写超时
这些参数默认值（如 net_write_timeout=60）在弱网环境下极易被击穿。
连接池和应用层不重试会让问题更隐蔽
很多框架（如 SQLAlchemy、MyBatis）默认使用连接池，但池中连接若已失效却未做有效性校验，就直接复用给存储过程调用——结果不是报错，而是静默失败或部分执行（比如只完成前几行 INSERT，没走到 COMMIT）。更麻烦的是，如果应用没捕获 OperationalError(2013) 并重试，就会出现“过程看似没执行，但部分数据已写入”的数据不一致。
- PyMySQL 默认不启用连接有效性检查，需手动加
ping=True参数 - HikariCP 需配置
connection-test-query=SELECT 1和validation-timeout - Spring Boot 中若用
spring.datasource.hikari.connection-test-query未设置，CALL失败后连接仍留在池中
别只调大 wait_timeout，重点看 net_write_timeout
很多人只盯着 wait_timeout，但远程不稳定下真正致命的是 net_write_timeout——它控制 MySQL 往客户端发数据时能等多久。一旦网络卡顿，哪怕只丢一个 TCP 包，这个计时器就归零，连接直接断开，过程回滚（除非显式用了 DECLARE CONTINUE HANDLER 捕获）。
- 查当前值：
SHOW VARIABLES LIKE 'net_write_timeout'; - 临时调高（仅会话级）：
SET SESSION net_write_timeout = 180; - 生产建议设为 120～300 秒，并配合应用层设置 socket timeout ≥ 此值
真正难处理的，是那些既没设重试、又没做连接健康检查、还依赖存储过程完成关键业务逻辑的旧系统——它们不会报错，但会在凌晨三点 quietly 丢掉一笔订单。
