conn.close()不一定能立刻释放连接，因MySQL连接池或网络延迟导致底层TCP连接延迟断开，服务端“Sleep”状态连接可能持续数秒，高频请求易触发Too many connections错误。
为什么conn.close()不一定能立刻释放连接
MySQL连接池或网络延迟可能导致conn.close()调用后，底层TCP连接并未立即断开，尤其在使用pymysql或mysql-connector-python时。服务端看到的“Sleep”状态连接可能持续数秒，叠加高频请求就容易触发Too many connections错误。
- 显式调用
conn.close()是必须的，但不能依赖它“即时生效” - 若使用
with语句（如pymysql.connect()不支持直接with，需包装），务必确认上下文管理器真正执行了close() - 检查是否重复创建连接：每次查询都
pymysql.connect(...)却不复用，比忘记关闭更危险
用connection_pool替代频繁新建连接
手动管理单个连接极易遗漏关闭，且无法控制并发上限。用连接池（如DBUtils.PooledDB或SQLAlchemy内置池）才是防溢出的正解。
-
PooledDB初始化时指定maxconnections=10，超限会阻塞而非报错 - 从池中获取的
conn调用close()实际是归还连接，不是销毁——这点和直连完全不同 - 避免在函数内无条件
pool.connection()却不确保归还，比如异常路径漏掉conn.close()
from DBUtils.PooledDB import PooledDB
import pymysql
<p>pool = PooledDB(
creator=pymysql,
maxconnections=8,
host='localhost',
user='root',
password='123',
database='test'
)</p><h1>正确：用完即close，归还给池</h1><p>conn = pool.connection()
try:
cursor = conn.cursor()
cursor.execute("SELECT 1")
finally:
conn.close() # 这里不是断开，是归还查连接泄漏：用SHOW PROCESSLIST定位源头
当MySQL出现大量Sleep连接时，先别急着改代码，用SQL确认哪些IP、用户、命令在堆积连接。
- 执行
SHOW PROCESSLIST，重点关注Time列大于60秒且Command为Sleep的行 - 结合应用日志，比对相同时间点的请求路径——常暴露在未捕获异常的数据库操作之后
- 注意
wait_timeout和interactive_timeout设置（默认28800秒），过长会掩盖问题
异步场景下aiomysql的close()要配合await
用aiomysql时，conn.close()是协程，不await就等于没关。常见错误是写成conn.close()（同步调用），实际什么也没发生。
立即学习“Python免费学习笔记（深入）”；
- 必须写
await conn.close()，且确保该await被执行（比如放在finally块） - 连接池
aiomysql.Pool的close()也是协程，应用退出前要await pool.close() - 不要在
__del__里尝试关闭异步连接——事件循环可能已关闭，引发RuntimeError
连接数溢出从来不是单点问题，而是连接生命周期管理松散的综合结果。最隐蔽的泄漏往往藏在异常分支、异步回调、或全局单例误复用里。盯住SHOW PROCESSLIST，再反向追踪代码里的每个connect和close配对，比盲目调大MySQL的max_connections管用得多。
