MySQL连接未显式关闭或事务未提交/回滚会导致连接堆积、Too many connections报错及锁表等问题，需确保conn.close()配对、事务完整结束，并在异步环境中避免连接复用。
MySQL连接没关，查完就卡住
代码执行完 SELECT 就不动了，或者跑几次就报 Too many connections —— 八成是没显式关闭连接。MySQL 的连接不是用完自动回收的，尤其在长连接池没配或没启用时，conn.close()（或等价操作）漏掉，连接就一直占着不放。
常见于手写 DAO、脚本直连、或误以为“函数退出就自动释放”。Python 的 mysql-connector-python、Go 的 database/sql、Java 的 Connection 都一样：不关，就留着。
- 检查所有
connect()/new Connection()后是否配对了close()、disconnect()或defer conn.Close() - 避免在异常分支里跳过关闭：用
try/finally或with语句包裹（Python），或defer（Go） - 别依赖 GC 触发关闭：MySQL 驱动的
__del__或finalize不可靠，且延迟不可控
用了 connection pool 还爆连接数？
开了连接池不代表能随便乱用。如果每次查询都 pool.Get() 却不 pool.Put() 或没设超时，连接照样堆积。更常见的是：池子本身配置太小，但并发请求多，导致新请求排队甚至失败；或池子太大，把 MySQL 的 max_connections 打满了。
关键不是“有没有池”，而是“池怎么管”。比如 Python 的 SQLAlchemy 默认用 QueuePool，但 pool_size=5 + max_overflow=10 意味着最多 15 个连接同时存在；而 MySQL 默认 max_connections=151，几十个服务实例一齐上，很快见底。
- 确认驱动层是否真启用了池：如 Go 的
db.SetMaxOpenConns(n)必须显式调，不是默认开 - 设
SetMaxIdleConns和SetConnMaxLifetime，防空闲连接长期占用又失效 - 查 MySQL 实时连接：
SHOW PROCESSLIST，看Command列是不是一堆Sleep，状态为Sleep且Time很大，就是没归还
事务里忘了 commit/rollback 就关连接？
这是个隐蔽坑：连接关了，但事务没结束，MySQL 会把它挂起，连接状态变成 Sleep，锁还占着，后续查询可能被阻塞。尤其在调试时加了 print 就 return，跳过了 commit()，再关连接，等于留了个半开事务。
现象是：表莫名锁住、SELECT ... FOR UPDATE 卡死、information_schema.INNODB_TRX 里有长时间运行的事务。这时候关连接只是“断开客户端”，服务端事务还在。
- 所有
begin()后必须有对应commit()或rollback()，哪怕只读也要明确结束 - 用上下文管理（如 Python 的
with conn.begin() as trans:）比手动控制更安全 - 开发期可开 MySQL 的
innodb_rollback_on_timeout=ON和wait_timeout缩短自动清理时间，但不能替代代码修复
异步/协程环境里连接复用错乱
在 asyncio（Python）、tokio（Rust）或 Node.js 的 mysql2 里，一个连接对象不能跨协程并发使用。如果多个 await 查询共享同一个 conn，轻则报 Commands out of sync，重则数据错乱或连接卡死——因为底层 TCP 流是顺序的，你发两个 query 没等第一个回，第二个就插进去了。
这不是连接没关的问题，而是“连接被当线程安全对象用了”。正确做法是每个协程拿自己的连接（从池里取），用完归还，而不是全局单例或闭包里存一个 conn 变量。
- 别在模块级或类属性里存
conn，尤其带async方法的类 - 用
async with pool.acquire() as conn:（aiomysql）或await pool.getConnection()（mysql2）确保隔离 - 注意 ORM 如 TortoiseORM 默认用连接池，但
get_or_create等方法内部也可能隐式开事务，得看文档是否自动提交
最麻烦的不是找不到哪行没关连接，而是连接关了但事务没结束，或者协程里复用了连接——这两类问题不会立刻报错，但会在高并发或长时间运行后突然爆发，日志里还很难定位到源头。
