直接执行SHOW VARIABLES LIKE 'max_connections';查最大并发连接数，SHOW STATUS LIKE 'Threads_connected';查当前活跃连接数，二者均为瞬时准确值。
怎么查当前连了多少个、上限设了多少
想知道数据库当前的连接状况和天花板在哪里？方法其实很简单，直接登录MySQL，运行下面两条命令，结果一目了然，完全不用去配置文件里大海捞针：
SHOW VARIABLES LIKE ‘max_connections’;—— 这条命令告诉你服务端允许的最大并发连接数上限，返回的可能是151或者500这样的数字。SHOW STATUS LIKE ‘Threads_connected’;—— 这条命令显示的是此时此刻实际活跃的连接数量。注意，它和SHOW PROCESSLIST显示的行数在数值上通常一致，但意义更精准。
这里有个关键点需要厘清：Threads_connected 是一个动态的瞬时值，会随着应用程序建立或断开连接而实时波动。而 max_connections 则是一个硬性限制，一旦连接数超过这个值，数据库就会毫不客气地抛出 ERROR 1040: Too many connections。另外，千万别把 SHOW PROCESSLIST 的输出行数当作连接总数——普通权限的账号只能看到自己发起的连接，而 Threads_connected 才是全局的真实全量数据。
SET GLOBAL max_connections 生效但不持久
如果遇到连接数瓶颈，想临时救急，可以用 SET GLOBAL max_connections 命令来立刻抬高上限。不过，这个方法有个明显的短板：它的效果只维持到MySQL下次重启为止。
- 执行这条命令前，务必确认账号拥有
SUPER权限，否则普通应用账号会收到ERROR 1227 (42000): Access denied的提示。 - 如果执行时报错
ERROR 1238 (HY000): Variable ‘max_connections’ is a read only variable，那通常意味着MySQL实例以--skip-grant-tables模式启动，或者设置了read_only=ON，在这种情况下动态修改是无效的。 - 命令执行成功后，新上限会立即生效，无需重载服务。但别忘了，还得确认操作系统层面的文件描述符限制没有拖后腿：用
ulimit -n查看，其值建议至少要比你新设的max_connections高出20%（例如，计划设到600，那ulimit -n最好不低于720）。
一个常见的操作误区是：在容器环境里执行了 SET GLOBAL，结果容器一重建，所有改动都归零了。原因就在于，这个改动没有写入配置文件，也没有通过启动脚本固化下来。
永久生效必须改 my.cnf/my.ini 的 [mysqld] 段
想让连接数上限的调整永久生效，必须修改MySQL的配置文件。在Linux系统上，文件通常是 /etc/my.cnf 或 /etc/mysql/my.cnf；Windows系统则是安装目录下的 my.ini。操作很简单，在 [mysqld] 配置段下添加一行即可：
max_connections = 500
添加完成后，重启MySQL服务：
- 使用systemd的系统：
sudo systemctl restart mysql（如果是MariaDB，则替换为mariadb） - 旧式的init系统：
sudo service mysql restart - 对于云数据库（如阿里云RDS、腾讯云CDB），通常不支持直接修改主机配置文件，需要通过云平台的控制台调整参数模板，或者提交工单申请修改。
重启后，务必验证一下：再次执行 SHOW VARIABLES LIKE ‘max_connections’;，确认数值已经更新。如果发现还是旧值，那就要检查一下了：是不是把配置行写错了段落（必须写在 [mysqld] 下面，写在 [client] 段或者文件末尾是无效的）？或者，启动命令中通过 --max_connections=200 这样的参数覆盖了配置文件里的设置？
调大连接数前先看 Max_used_connections 和资源余量
盲目调高 max_connections 的数值意义不大，甚至可能有害。在动手之前，有两件事更重要：查看历史连接峰值，以及评估服务器资源是否扛得住。
- 查看历史峰值：执行
SHOW GLOBAL STATUS LIKE ‘Max_used_connections’;，这个值记录了自上次MySQL启动以来，同时使用的连接数的最高峰。如果长期来看，Max_used_connections / max_connections的比值小于0.5，那就说明你设置的上限过高了，大量连接名额被闲置，白白消耗了服务器的内存。 - 评估服务器资源：每个MySQL连接都会占用至少几MB的内存。一台只有1G内存的机器，如果把
max_connections设到500，很可能会引发Cannot allocate memory这类内存不足的错误。 - 连接池配置是关键：很多时候，问题出在应用端。比如，Spring Boot默认的HikariCP连接池，其
maximum-pool-size可能只设为20，而你却把MySQL端的max_connections调到了1000，这纯粹是一种资源浪费。应用连接池的大小，才是真正应该精细调控的地方。
话说回来，真正导致“连接数过多”问题的，往往不是上限设得太低，而是其他更深层次的原因：比如应用程序存在连接泄漏（打开后没有正确关闭）、长事务阻塞导致连接无法释放，或者DNS解析失败造成认证连接堆积。排查这些问题，需要借助 SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 60; 这样的查询来分析长时间运行的连接，并结合慢查询日志进行综合判断。单纯调大 max_connections，不过是扬汤止沸，解决不了根本问题。
