MySQL连接空闲超时被服务端关闭后，应用仍使用失效连接导致“server has gone away”错误；需在execute前调用ping(reconnect=True)，SQLAlchemy应配置pool_pre_ping=True，并避免依赖连接池自动清理。
MySQL 连接超时断开后 execute() 报 MySQL server has gone away
这是典型的连接空闲超时被服务端主动关闭，但应用还拿着旧连接对象继续用。MySQL 默认 wait_timeout 是 28800 秒（8 小时），但很多云数据库或中间件会设成 5–15 分钟，更短。
关键不是“连不上”，而是“连着却失效了”——连接对象还在内存里，ping() 没调、execute() 一发就崩。
- 别依赖连接池的“最大空闲时间”自动清理：有些池（如 PyMySQL 的
Pool）不主动探测，只等下次取用时才暴露问题 - 写业务逻辑前先加
conn.ping(reconnect=True)，尤其在长周期任务（比如 Celery task、定时脚本）开头 - 如果用的是
SQLAlchemy，确保配置了pool_pre_ping=True，它会在每次从池取连接时发一个轻量PING包 -
reconnect=True在 PyMySQL / MySQLdb 中只是尝试重连，不保证事务上下文延续——已开启的事务会丢，得自己捕获异常后重试整个业务逻辑
Python 用 pymysql 配置自动重连但还是失败
pymysql 的 autocommit 和 reconnect 是两回事：reconnect=True 只影响连接对象在抛出异常后的自动重建行为，但默认是 False，且不处理执行中中断。
常见误区是以为设了 reconnect=True 就万事大吉，其实它只对部分错误生效（比如连接断开但没发请求），而 server has gone away 这类错误发生时，连接对象内部状态已损坏，必须显式重连。
- 初始化连接时务必传
reconnect=True，但不能只靠它 - 所有可能跨过空闲期的查询，都应在
execute()前加cursor.connection.ping(reconnect=True) - 避免在连接对象上长期持有
cursor：一次查询一个 cursor，用完就丢，不要复用旧 cursor 对象 - 注意
ping()本身也可能失败（比如网络瞬断），需包一层try/except，失败则重新建连接
心跳检测该放服务端还是应用端？
服务端心跳（比如 MySQL 的 tcp_keepalive）只能保底层 TCP 连接不断，但解决不了 MySQL 协议层的 wait_timeout 断连；应用端心跳才是关键。
所谓“心跳”，就是定期发一个低成本语句（如 SELECT 1）确认连接可用。但它不是越勤越好——太频繁增加无谓压力，太懒又起不到作用。
- 心跳间隔必须 严格小于 数据库的
wait_timeout（建议设为 timeout 的 70%） - 不要用后台线程轮询所有连接：连接池里的空闲连接数是动态的，轮询既难管理又易漏
- 推荐方式：在连接被取出使用前做一次
ping()，即“按需心跳”，兼顾准确性和低开销 - 如果用
mysql-connector-python，它的pool_reset_session=False可能导致重连后 session 变量丢失，要注意是否依赖@user_var或临时表
连接池大小与重连并发冲突
当大量连接同时触发重连（比如服务刚重启、网络抖动后恢复），MySQL 可能因并发连接暴增被打满，报错 Too many connections，反而让问题雪上加霜。
这不是代码 bug，而是资源协调失衡：连接池“想修好连接”，数据库“觉得你在攻击我”。
- 设置连接池的
max_overflow（如 SQLAlchemy）或maxsize（如 DBUtils）要留余量，但别盲目调高 - 避免所有 worker 同时启动时集中建连：加一点随机延迟（比如 0–2 秒），打散初始连接洪峰
- 重连失败时别立即重试，用指数退避（如 1s → 2s → 4s），防止重试风暴
- 监控
Threads_connected和Aborted_connects这两个状态变量，它们比应用日志更能早发现问题模式
最麻烦的不是连不上，是连着却不可用；最隐蔽的不是没心跳，是心跳没覆盖到真正用连接的那一刻。
