应使用连接池复用 MySQL 连接以提升性能并避免连接数超限：启动时预建连接，请求时分配并归还；需及时释放、设置合理空闲与存活时间，并按读写场景分池管理。
频繁创建 MySQL 连接会显著拖慢应用性能，增加数据库服务器负担，还可能触发连接数限制。核心解决思路是复用连接，而非每次请求都新建——关键在于合理使用连接池和规范连接生命周期管理。
用连接池代替直连
连接池在应用启动时预先创建一批连接，请求来时从中分配，用完归还而非关闭。主流语言都有成熟实现：
- Java 推荐 HikariCP（轻量、高性能），配置 maximumPoolSize 避免过多空闲连接
- Python 可用 SQLAlchemy 的 QueuePool 或 DBUtils，设置 pool_size 和 max_overflow
- Node.js 常用 mysql2 的 createPool()，注意调整 connectionLimit 和 waitForConnections
及时释放连接，避免泄漏
连接不归还会导致池耗尽，后续请求阻塞或报错。务必确保每个获取的连接最终被释放：
- 使用 try/finally 或语言级资源管理语法（如 Python 的 with、Java 的 try-with-resources）
- 避免在事务中长时间持有连接；业务逻辑复杂时，先查数据再处理，不要让连接卡在计算或外部调用上
- 检查异常路径：网络超时、SQL 报错等场景下，连接是否仍被正确 close 或 return
合理设置连接空闲与存活时间
过长的空闲连接可能被中间件（如代理、防火墙）或 MySQL 自身（wait_timeout）断开，引发“Lost connection”错误：
- 启用连接池的 testOnBorrow 或 validationQuery（如 SELECT 1），借出前检测有效性
- 设置 minIdle 和 maxIdle 控制池中空闲连接数量，避免资源浪费
- 将连接池的 maxLifetime 设为略小于 MySQL 的 wait_timeout（默认 8 小时），强制刷新老化连接
区分读写场景，按需配置
高并发读多写少场景下，可考虑读写分离连接池：
- 主库连接池专注写操作，连接数可设小些；从库连接池承接读请求，适当扩大规模
- 避免在同一个连接上混用事务内读写与后续只读查询，防止从库连接被意外用于写操作
- 使用中间件（如 ProxySQL、ShardingSphere）或客户端 路由 逻辑，自动分发语句到合适连接池
不复杂但容易忽略：连接管理不是写一次就完事，要结合监控（如池中活跃 / 空闲连接数、等待请求数）持续调优。上线后观察慢日志和连接状态，及时发现泄漏或配置失当。
