当前位置：首页 > 问答 > 正文

MySQL最大连接数到底该怎么定才不会卡也不浪费资源呢？

黎家
问答
2026-01-18 22:12:16
2

要搞清楚MySQL最大连接数到底设多少才合适，咱们得先弄明白这个“最大连接数”到底是个啥，简单打个比方，你的MySQL数据库就像一家餐厅，而“最大连接数”就是这家餐厅同时能容纳的餐桌数量，每个来吃饭的客人（也就是你的应用程序发起的请求）都需要一张桌子（一个数据库连接）来点菜、吃饭。

问题就来了：餐厅摆多少张桌子才最合适呢？

摆得太少（最大连接数设得过低），高峰期客人一来，发现没空桌了，只能在外面排队干等着，反映到数据库上，就是应用程序无法建立新的连接，用户会看到“连接超时”或“服务器繁忙”的错误，感觉就是“卡死了”,这显然是不行的。

那是不是桌子摆得越多越好呢？也不是，摆得太多（最大连接数设得过高），餐厅面积有限（对应服务器的硬件资源，比如CPU、内存是有限的），如果摆了1000张桌子，平时只有100个客人，那900张桌子空着，不仅占地方，每天打扫维护也费劲（对应MySQL会为每个可能的连接预留一些内存，连接数设得过高会浪费内存资源），更可怕的是，万一真的突然来了1000个客人，所有桌子都坐满了，后厨（对应数据库的CPU和磁盘IO）只有两个厨师，根本炒不过来那么多菜，结果就是每张桌子的客人都等得怨声载道，上菜极慢，整个餐厅陷入混乱，在数据库里，这就是大量的并发连接争抢有限的CPU和磁盘资源，导致每个查询都变得非常慢，同样会让系统“卡死”。

我们的目标就是找到那个“黄金点位”：既能满足高峰期的客流,又不会因为过度扩张导致资源竞争和服务质量下降。

MySQL最大连接数到底该怎么定才不会卡也不浪费资源呢？

具体该怎么找这个点位呢？你不能光靠猜，得看数据,主要看以下几个方面：

观察平时的客流（监控当前连接数）：这是最重要的一步，MySQL自己就记录了连接数的信息，你可以通过一些监控工具（比如Prometheus+Grafana，或者云服务商自带的监控），长期观察数据库的“Threads_connected”这个指标（它表示当前已经建立的连接数）,重点看：
- 平时是多少？ 比如白天业务繁忙时平均有150个连接。
- 最高峰是多少？ 比如做活动时,曾经达到过400个连接。
- 夜间低谷是多少？ 比如夜里可能只有20个连接。
根据《高性能MySQL》等书籍中的建议，你设定的最大连接数，应该比你在监控中观察到的历史最高峰值还要留出一定的余量（比如20%-30%），比如你观察到最高峰是400，那么你可以先设定为500或600,这相当于给餐厅预留了一些应对突发客流的备用桌。
看看服务器的“体力”（检查硬件资源）：餐厅能接待多少客人，最终还得看后厨的炒菜能力和服务员的跑堂速度，数据库也一样，它的“体力”就是CPU、内存和磁盘IO。
- 在连接数达到高峰时，你需要监控服务器的CPU使用率是否过高（比如持续超过80%）、内存是否紧张（特别是Swap交换空间是否被频繁使用）、磁盘IO是否忙不过来。
- 如果发现连接数一高，这些硬件指标就“爆表”了，那么即使你把最大连接数设得再高也没用，系统照样会卡，这时候你要考虑的就不是增加连接数了，而是要么优化SQL查询（让每个客人吃饭更快），要么升级服务器硬件（扩大后厨、请更多厨师）。
优化应用程序的“用餐习惯”（使用连接池）：这是非常关键且有效的一点，想象一下，如果每个客人吃完一口菜就离席，然后马上又回来坐下点菜，那再多的桌子也不够用，糟糕的应用程序代码就是这样，每次执行一个SQL查询就新建一个连接,用完马上关闭。
- 正确的做法是使用连接池，连接池相当于一个“餐桌管理站”，应用程序需要连接时，不是直接找MySQL要，而是从连接池里借一个现成的；用完后，不是关闭连接,而是还给连接池。
- 这样做的好处是，避免了频繁创建和销毁连接的巨大开销（摆桌子和收桌子是很费时间的），使得有限的数据库连接可以被高效复用，这样一来，可能只需要100个连接池中的连接，就能承担原来需要300个临时连接才能完成的请求，这极大地降低了对最大连接数的需求，也减轻了数据库的压力，绝大多数编程语言（Java的HikariCP，Go的database/sql等）都有成熟高效的连接池库。
一个实用的起步值：如果你完全没有头绪，可以参考一个常见的经验法则，根据许多运维工程师的实践经验，对于多数中小型Web应用，可以将max_connections初始值设置为200到500之间，这是一个相对安全的范围，既不会太低导致轻易爆满，也不会太高而过度消耗内存，再基于上面提到的监控数据,进行精细调整。