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() # 这里不是断开，是归还</p>
查连接泄漏：用SHOW PROCESSLIST定位源头
当MySQL出现大量Sleep连接时，先别急着改代码，用SQL确认哪些IP、用户、命令在堆积连接。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 执行
SHOW PROCESSLIST，重点关注Time列大于60秒且Command为Sleep的行 - 结合应用日志，比对相同时间点的请求路径——常暴露在未捕获异常的数据库操作之后
- 注意
wait_timeout和interactive_timeout设置（默认28800秒），过长会掩盖问题
异步场景下aiomysql的close()要配合await
用aiomysql时，conn.close()是协程，不await就等于没关。常见错误是写成conn.close()（同步调用），实际什么也没发生。
- 必须写
await conn.close()，且确保该await被执行（比如放在finally块） - 连接池
aiomysql.Pool的close()也是协程，应用退出前要await pool.close() - 不要在
__del__里尝试关闭异步连接——事件循环可能已关闭，引发RuntimeError
连接数溢出从来不是单点问题，而是连接生命周期管理松散的综合结果。最隐蔽的泄漏往往藏在异常分支、异步回调、或全局单例误复用里。盯住SHOW PROCESSLIST，再反向追踪代码里的每个connect和close配对，比盲目调大MySQL的max_connections管用得多。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
