搞网站的人，多少都听过Too many connections这个报错，真遇上的时候那叫一个心慌——数据库直接罢工，网站跟着全瘫，用户刷出来全是错误页。其实这个报错翻译过来就一句话：连接数到顶了，数据库忙不过来，后面的连接一律不接待。听起来吓人，但处理思路特别清晰，就是看现状、应急、找根因三步，我带你走一遍。
第一步：看看连接到底满没满
能登录数据库的话，先执行几条命令看看：SHOW VARIABLES LIKE ‘max_connections’看上限是多少；SHOW STATUS LIKE ‘Threads_connected’看当前连了多少；SHOW STATUS LIKE ‘Max_used_connections’看历史最高冲到多少。要是历史最高经常贴着上限跑，那是配置真的不够或者并发真的高；要是当前连接数异常高，而且一堆连接都闲着没事干（Sleep状态），那基本就是连接泄漏了。
第二步：先救火，把网站拉起来
业务正瘫着呢，先应急。两条路：一条是把max_connections临时调大，SET GLOBAL max_connections = 500这么干，马上生效，但重启数据库会丢，得再改配置文件才能永久生效；另一条是把那些闲着没事干的空闲连接掐掉，先查出来再KILL，给新请求腾地方。
注意啊，调大上限之前得掂量掂量：每个连接都要吃内存，你1G内存的机器硬把上限调到几千，内存直接爆，数据库反而死得更快。调上限是救急，不是治病，真正的病根还得往下找。
第三步：根因才是关键，别光救火
连接数被打满，根子上就那么几种：应用没好好释放连接，连接池没配好或者异常路径忘了归还连接，这是最高发的，查应用日志和连接池配置；有慢查询占着茅坑不拉屎，一条SQL跑几十秒，连接一直被占着，看慢查询日志；再有就是突发流量超了设计容量，或者干脆被人扫描攻击，数据库端口怼着公网，人家脚本一上来就乱连。
连接池这块儿我得重点说：应用连接池的最大连接数，别拍脑袋定，各应用加起来别超过数据库上限的七八成，留点余量。不然你这边应用连池拉满，数据库那边早爆了，两边都觉得自己没问题，其实都是配置惹的祸。
事后得补上的两件事
救完火，有两件事一定要补。一是把数据库连接数的监控接上，Threads_connected、Max_used_connections这些指标设个告警，快打满的时候提前通知你，别等瘫了才发现。二是想清楚容量规划，业务增长是必然的，连接数上限、服务器配置都得跟着涨，不然今天救完明天接着爆，那就成救火队员了。
再补一刀：数据库端口别对着公网
排查连接数问题的时候，顺带检查一下数据库端口是不是暴露在公网上。很多人图省事，安全组把3306对全网开放，结果被扫描器盯上，天天有人拿脚本撞库试密码，连接数不爆才怪。数据库只该让应用服务器通过内网访问，公网端口能关就关，关不了就限制来源IP。这一步做好，能挡掉一大半莫名其妙的连接数暴涨，比天天救火强多了。
另外提一嘴，网站程序那边也要看一眼：有些框架默认连接池配得特别激进，一启动就占几十个连接，几个服务一叠，数据库就受不了了。连接池的初始连接数、最大连接数都调温和一点，够用就行，别一上来就梭哈。
最后说句实在话
Too many connections这报错吧，处理过一次你就有经验了：先看监控确认连接为啥满，应急时合理调上限、清空闲连接，再回头把应用的连接池、慢查询这些根子问题解决掉，最后用监控兜底。光调参数不除根因，问题迟早以更猛烈的姿势回来。这行当里，救火谁都会，防火才是本事。反正记住：数据库连接数这东西，平时多留个心眼，监控设好、端口关好、连接池调好，它能安安稳稳陪你很久；真要出事了也别慌，按今天这套路子走，能救回来。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
