mysql最大并发连接数默认151，可临时用set global修改或永久配置my.cnf；但需同步调高ulimit和limitnofile，并排查sleep连接堆积、连接池泄漏及慢查询等根本原因。
如何查看和修改 MySQL 的最大并发连接数（max_connections）
MySQL 默认的 max_connections 通常是 151，远低于高流量业务的实际需求。直接在运行中调整它即可生效，但要注意：改得太大会占用更多内存（每个连接约占用 256KB–1MB 内存），且不解决根本瓶颈。
实操建议：
- 先查当前值：
SHOW VARIABLES LIKE 'max_connections'; - 临时修改（重启失效）：
SET GLOBAL max_connections = 2000; - 永久修改需编辑配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]下添加：max_connections = 2000
，然后重启mysqld - 注意系统级限制：Linux 的
ulimit -n和systemd的LimitNOFILE可能卡住实际生效值，需同步调高
为什么单纯调高 max_connections 常常没用
很多场景下，即使把 max_connections 设到 5000，应用仍报 Too many connections，本质是连接没被及时释放——比如应用层未正确关闭 Connection，或连接池配置不合理。
关键点：
- 检查真实活跃连接：
SHOW STATUS LIKE 'Threads_connected';和SHOW PROCESSLIST;看是否大量Sleep状态连接堆积 - 确认应用是否复用连接：PHP 的
mysql_pconnect、Java 的 HikariCP / Druid 连接池必须配置maxLifetime、idleTimeout，否则连接长期空闲不释放 - MySQL 自身超时参数影响大：
wait_timeout（非交互式连接）和interactive_timeout（交互式）默认 28800 秒（8 小时），线上建议设为 300–600 秒
连接数暴增时的快速定位方法
当连接数突然飙升，优先排查异常行为而非立刻扩容。重点看谁在“占着茅坑不拉屎”。
操作步骤：
- 按用户统计连接数：
SELECT user, COUNT(*) FROM information_schema.PROCESSLIST GROUP BY user; - 找长时间 Sleep 的连接：
SELECT id, user, host, db, command, time, state, info FROM information_schema.PROCESSLIST WHERE command = 'Sleep' AND time > 300; - 结合慢查询日志分析：开启
slow_query_log并设long_query_time = 1，确认是否有未加索引的查询拖住连接 - 检查应用日志里是否频繁出现
Connection reset或重试逻辑，可能引发连接雪崩
比调大 max_connections 更有效的并发优化手段
真正压垮数据库的往往不是连接数上限，而是单个查询的资源消耗、锁竞争或磁盘 I/O。盲目增加连接数反而加剧争抢。
更值得投入的优化方向：
- 给高频查询加覆盖索引，避免
Using filesort或Using temporary—— 这类查询哪怕只慢 200ms，100 个并发就足以让线程队列堵死 - 拆分大事务：把一个更新 10 万行的事务，拆成每次 1000 行 +
SLEEP(0.01)，降低锁持有时间 - 读写分离：用
read_only=ON配合从库分担查询压力，尤其对报表类长查询 - 启用查询缓存（仅限 MySQL 5.7 及以前）或迁移到
Redis缓存热点结果，减少重复执行
连接池配置错误、慢查询、锁等待这三类问题，占了线上连接耗尽故障的 80% 以上。调 max_connections 是止痛药，不是手术刀。
