MySQL短连接频繁创建导致CPU和TIME_WAIT激增，应改用长连接或连接池复用；PHP需mysqlnd驱动+PDO的p:前缀或mysqli_pconnect()，Python推荐DBUtils.PooledDB并正确归还连接。
MySQL 短连接频繁创建导致 CPU 和 TIME_WAIT 暴涨
每次 mysql_connect() 或 new PDO() 都会新建 TCP 连接，握手 + 认证 + 关闭，光是三次握手和四次挥手就占掉几毫秒；高并发下服务器很快堆满 TIME_WAIT 状态连接，netstat -an | grep TIME_WAIT | wc -l 轻松破万。更糟的是，MySQL 服务端要反复分配/销毁线程、初始化会话变量、加载权限——这些开销远超 SQL 执行本身。
常见错误现象：Can't create thread (errno 11)、Too many connections、监控里 Threads_created 每秒飙升、应用层报 “Connection refused” 但 max_connections 远未到上限。
- 别用脚本循环里写
mysqli_connect()+mysqli_close()—— 这是典型短连接滥用 - PHP-FPM 模式下，每个请求生命周期内只应建立 1 次连接（或复用已有），而不是每查一次建一次
- Python 的
pymysql.connect()默认也是短连接，不手动close()会延迟释放，但依然无法复用到下一个请求
PHP 中正确开启 MySQL 长连接（mysqlnd + persistent）
PHP 的长连接不是“连上就不关”，而是把连接放进程/线程的连接池里，供后续请求复用。关键在驱动层支持和配置方式：用 mysqlnd（PHP 5.4+ 默认）才能真正复用；libmysqlclient 的 pconnect 实现有缺陷，容易卡死或漏回收。
- DSN 中加
p:前缀：PDO 构造时用mysql: host=...;dbname=...;unix_socket=/tmp/mysql.sock→ 改成mysql:host=...;dbname=...;unix_socket=/tmp/mysql.sock不行，必须是mysql:p:host=... - mysqli 函数族要用
mysqli_pconnect()，不是mysqli_connect()；且不能调mysqli_close()，否则会主动断开长连接 - FPM worker 进程重启（如 reload 配置）才会清空其持有的长连接，所以连接数不会无限增长，但要注意
mysql.wait_timeout（默认 8 小时）和interactive_timeout设置，避免连接被服务端单方面 kill 后 PHP 还以为它活着
Python 用 PyMySQL / mysql-connector-python 开启连接池
Python 没有原生长连接概念，得靠连接池管理复用。PyMySQL 自带 PyMysqlPool 不推荐（维护差、bug 多），直接用 DBUtils.PooledDB 或现代方案 SQLAlchemy + QueuePool。
-
DBUtils.PooledDB初始化时设mincached=5, maxcached=20, maxshared=0, blocking=True——maxshared=0表示连接不跨线程共享（避免事务污染），blocking=True是关键，否则取不到连接直接抛异常 - 用完连接必须
pool.connection().close()—— 这里close()不是断开，而是归还给池；漏掉这句会导致连接泄露，池子慢慢耗尽 - mysql-connector-python 的
pool_size参数只控制最大连接数，不自动归还；必须显式调connection.close()才进池，且需确保autocommit=False时事务已提交/回滚，否则连接归还后状态残留
连接池参数调不好反而更慢
池子太小，请求排队等连接，wait_timeout 内没等到就超时；池子太大，MySQL 服务端线程数打满，Threads_running 持续高位，锁竞争加剧，响应毛刺变多。这不是“越大越好”的问题。
- 先看业务平均 QPS 和 SQL 耗时：假设每请求平均 2 条 SQL、每条 50ms，QPS=200 → 并发连接需求 ≈ 200 × 0.05 × 2 = 20，池大小设 25–30 比较安全
-
wait_timeout必须 > 应用最长 SQL 执行时间，否则连接中途被杀，客户端收到Lost connection to MySQL server during query - 别让连接池自动 ping：有些库默认开启
ping检活，每取一次连接都发个SELECT 1，QPS 翻倍还测不准真实负载；改成连接归还时检测，或用 MySQL 8.0+ 的tcp_keepalive更轻量
连接复用这件事，核心不在“怎么连”，而在“谁负责清理、什么时候清理、清理后状态是否干净”。漏掉事务 rollback、没关 result set、连接归还前没重置字符集，都会让下一个请求踩坑。这些细节比选什么池子重要得多。
