调整 max_connections 能解决连接数不足报错，但会增加内存消耗，适合连接排队场景，不适合 CPU 瓶颈场景。

命令速用版

以下命令用于查看当前配置和临时修改，重启后失效。

SHOW VARIABLES LIKE 'max_connections';
SET GLOBAL max_connections = 500;

永久修改需编辑配置文件，通常为 /etc/my.cnf 或 /etc/mysql/my.cnf。

[mysqld]
max_connections = 500

为什么会这样

max_connections 限制的是并发线程数，每个连接都会占用独立内存。

MariaDB 为每个客户端连接分配一个线程，线程需要栈空间和处理缓冲区。如果连接数设置过高而物理内存不足，操作系统会触发 OOM Killer 杀死数据库进程。高并发场景下，连接数不足通常表现为客户端等待或报错 Too many connections，但瓶颈也可能在于 CPU 处理能力或磁盘 I/O，单纯增加连接数无法解决非连接资源瓶颈。

分步处理

按顺序执行以下步骤，确保配置变更安全可控。

1. 检查当前连接使用情况

登录数据库执行以下命令，观察 Threads_connected 和 Max_used_connections。

SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';

如果 Max_used_connections 接近当前 max_connections 值，说明存在连接瓶颈。

2. 评估内存余量

检查服务器可用内存，确认增加连接后不会耗尽内存。公开资料中没有看到可靠的量化数据说明每个连接确切占用内存，因为取决于 thread_stack 和各缓冲區设置，但通常建议预留充足余量。

3. 修改配置文件

编辑 my.cnf 文件，在 [mysqld] section 下添加或修改 max_connections 值。

[mysqld]
max_connections = 500

4. 检查系统文件描述符限制

数据库连接数受操作系统 ulimit 限制，需确保 open files 限制大于 max_connections。

ulimit -n

如果数值过小，需修改 /etc/security/limits.conf 提升限制。

5. 重启服务

配置文件中修改 max_connections 需要重启 MariaDB 服务才能生效。

systemctl restart mariadb

怎么验证是否生效

通过变量检查和状态监控确认配置已应用且运行稳定。

1. 确认变量值

执行 SHOW VARIABLES 命令，确认返回值已更新。

SHOW VARIABLES LIKE 'max_connections';

2. 监控连接错误

观察 Connection_errors_max_connections 状态值，如果不再增长，说明连接限制已缓解。

SHOW STATUS LIKE 'Connection_errors_max_connections';

3. 检查系统日志

查看 /var/log/mysqld.log 或 journalctl -u mariadb，确认没有 OOM 或启动失败报错。

常见坑

以下场景容易导致配置失效或引发故障，操作前需谨慎评估。

1. 忽略 ulimit 限制

即使数据库配置了高连接数，如果操作系统限制文件描述符数量，新连接仍会失败。

2. 内存溢出风险

在内存较小的实例上调大 max_connections，容易触发系统 OOM 保护机制导致服务崩溃。

3. 未使用连接池

应用层直接建立大量短连接会浪费资源，建议优先在应用层配置数据库连接池。

常见问题

max_connections 默认值是多少？

MariaDB 10.6 的默认值通常为 151，具体取决于安装包和操作系统配置。

修改后需要重启数据库吗？

通过 SET GLOBAL 修改立即生效但重启失效，修改配置文件后必须重启服务。

调大连接数能提升查询速度吗？

不能，它只允许更多并发连接，查询速度取决于 SQL 效率和硬件资源。

参考来源

MariaDB Knowledge Base, Server System Variables - max_connections, https://mariadb.com/kb/en/server-system-variables/#max_connections