直接查show variables like 'max_connections'和show status like 'threads_connected'可快速确认是否因连接数超限；前者为上限，后者为当前活跃连接数，若二者接近即为瓶颈。
MySQL 报错 Too many connections 怎么快速确认是不是 max_connections 不够
直接查当前设置和实际使用量最靠谱。连上 MySQL 后跑这两条：
SHOW VARIABLES LIKE 'max_connections';<br>SHOW STATUS LIKE 'Threads_connected';前者是上限，后者是此刻真正在用的连接数。如果
Threads_connected 接近甚至等于 max_connections，基本就是它了。注意：有些监控工具或连接池会复用连接，但 Threads_connected 统计的是服务端真实活跃连接，比应用层日志更可信。
改 max_connections 要不要重启 MySQL
可以不重启，用 SET GLOBAL max_connections = 1000; 立即生效。但这个改动只在当前实例生命周期内有效，MySQL 重启后会丢。要永久生效，必须改配置文件（通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），在 [mysqld] 段里加一行：
max_connections = 1000改完记得
systemctl restart mysql 或对应服务命令。别漏掉配置文件写错段落（比如写到 [client] 下）——那行配置完全不生效。
设多大才合适：不是越大越好，得看内存和负载
每个连接至少占用 256KB～1MB 内存（取决于排序缓冲、临时表大小等），1000 连接可能吃掉 1GB+ 内存。常见坑是盲目调到 5000，结果 MySQL 因 OOM 被系统 kill。建议按公式粗估：max_connections ≈ (可用内存 × 0.7) / 每连接平均内存。线上环境先从 300～500 开始试；高并发短连接场景（如 PHP-FPM），配合连接池或 wait_timeout 缩短空闲连接存活时间更治本。
为什么调了 max_connections 还报错
常见原因有三个：
- 用户级限制没放开：
SHOW VARIABLES LIKE 'max_user_connections';如果是 0 以外的值，该用户的连接数会被单独卡住 - 操作系统限制：MySQL 进程能打开的文件描述符不够，
ulimit -n查看，通常要设成 65535 并在systemd服务配置里持久化 - 应用没正确释放连接：比如 PHP 的
mysqli忘了close()，或 Go 的db.Close()没调，连接一直挂着直到超时
max_connections。
调参这事，真正难的不是改数字，而是分清是资源瓶颈、配置遗漏，还是代码漏关连接——三者表现一样，根因完全不同。
