MySQL连接断开时OperationalError典型表现为(2013)或(2006)错误，源于wait_timeout、网络抖动等导致连接失效；需在execute前用ping(reconnect=True)主动检测，或用SQLAlchemy的pool_pre_ping=True自动重连。
MySQL连接断开时OperationalError的典型表现
Python用pymysql或mysql-connector-python连MySQL，运行中突然报OperationalError: (2013, 'Lost connection to MySQL server during query')或(2006, 'MySQL server has gone away')，基本可以确定是连接已失效但程序还在复用旧连接。这不是代码写错了，而是MySQL默认8小时wait_timeout自动断连，或网络抖动、服务重启导致的物理断开。
关键点：这个错误**不会在connect()时抛出**，而是在执行cursor.execute()时才暴露——所以单纯try-except单次execute不够，得在连接使用前做有效性验证。
手动检测并重连：用ping(reconnect=True)而不是捕获异常再重连
别等OperationalError发生再去重建连接——太被动，还可能漏掉事务上下文。PyMySQL和mysql-connector都支持ping()方法主动探测连接状态，且带reconnect=True参数可自动重连：
示例（PyMySQL）：
立即学习“Python免费学习笔记（深入）”；
conn = pymysql.connect(..., autocommit=True)
# 每次执行前检查
try:
conn.ping(reconnect=True) # 这里会静默重连，不抛异常
except Exception as e:
# ping失败说明连不上，需重新connect()
conn = pymysql.connect(...)
cursor = conn.cursor()
cursor.execute("SELECT 1")注意：ping(reconnect=True)只对PyMySQL 0.9+和mysql-connector 8.0.23+有效；老版本只能靠try/except OperationalError后手动重连，但必须清空旧cursor对象，否则仍会用已失效句柄。
用SQLAlchemy + pool_pre_ping=True实现透明重连
自己维护连接池容易出错，推荐直接上SQLAlchemy——它内置连接池，且pool_pre_ping=True会在每次从池里取连接前自动执行PING，失败则丢弃该连接、新建一个，应用层完全无感：
配置要点：
-
pool_recycle=3600：强制每小时重连一次，避免MySQL的wait_timeout生效 -
pool_pre_ping=True：每次engine.connect()前探测，比ping()更彻底 -
pool_timeout=30：获取连接超时时间，防死锁
示例URL（含参数）：
mysql+pymysql://user:pass@host:3306/db?charset=utf8mb4&pool_pre_ping=true&pool_recycle=3600
不用改业务代码，所有session.execute()或connection.execute()都会自动受益。但要注意：如果用了session.begin_nested()或保存点，pre_ping可能干扰事务一致性，此时应关掉pre_ping，改用pool_use_lifo=True + 更短的pool_recycle。
连接池大小设多少？别盲目调大pool_size
很多人以为“多开连接=吞吐高”，结果MySQL报Too many connections。实际并发请求数 ≠ 连接池大小。真实瓶颈常在MySQL的max_connections（默认151）、网络端口数、或Python GIL下的I/O等待。
建议起步值：
- Web服务（如Flask/FastAPI）：设
pool_size=10，max_overflow=20（突发时临时扩容） - 离线脚本/定时任务：用
NullPool（无池），每次需要时新建连接，用完立刻close() - 高并发微服务：先压测，观察MySQL的
Threads_connected和慢查询日志，再按需调
重点：连接池不是越大越好，闲置连接会占用MySQL资源，还可能因长时间空闲被中间件（如ProxySQL）或防火墙踢掉——这时pool_recycle比pool_size更关键。
真正难处理的是长事务+网络不稳定场景：连接在事务中被断开，pre_ping无法介入（事务期间不能ping），此时只能靠应用层捕获OperationalError后回滚并重试整个事务逻辑。这个兜底逻辑没法省略。
