当前最大连接数通过show variables like 'max_connections'查看，历史峰值用show global status like 'Max_used_connections'；若长期超80%需扩容，但须同步调高系统文件限制、评估内存与CPU负载，优先优化慢SQL而非盲目增加连接数。
查当前最大连接数和实际使用峰值
直接进 MySQL 执行：
就能看到当前生效值；再跑一句
，它告诉你历史上最高同时连了多少个——这个数字比
更关键。如果
长期卡在
的 80% 以上，说明快顶不住了；如果常年只有 10–20，那调高反而浪费内存。
临时改（只到下次重启）
命令行登录后执行：
立刻生效，适合紧急救火。但注意：这只是改了运行时变量，MySQL 进程一重启就回退到配置文件里的值。常见错误是改完以为万事大吉，结果半夜服务重启，
错误又来了。
永久改（必须配文件 + 检查系统限制）
编辑 MySQL 配置文件（
或
），在
段下加一行：
。但这只是第一步：
systemd 管理的服务（如 CentOS 7+/Ubuntu 16.04+）默认限制进程打开文件数，常卡死在 214 或 1024 —— 即使你配了 5000，MySQL 启动时也会默默按系统限制截断
必须同步改 systemd 服务单元：
（或
），在
下加
和
改完要执行：
，再
否则你会看到配置写了 1000，
却返回 214 —— 不是 MySQL 没读配置，是操作系统不放行。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
别盲目拉高，小心内存和 CPU 反被拖垮
不是越大越好。每个连接至少占几 MB 内存（尤其开了 sort_buffer、join_buffer），连接数翻倍，内存占用可能翻倍还多。更隐蔽的问题是：连接堆积会加剧锁竞争、线程上下文切换开销，CPU 使用率可能突然飙升。实测中，从 200 调到 2000 后 QPS 反而下降 15%，就是因为线程调度成了瓶颈。
真正该盯的是
（当前活跃连接数）和慢查询日志——多数“连不上”问题根源不在上限低，而在有长事务或慢 SQL 把连接池堵死了。先优化查询，再扩连接数。
系统级限制、内存水位、真实并发压力，这三样没摸清之前，光改
就像给漏水的桶拼命加水。
show variables like 'max_connections';show global status like 'Max_used_connections';max_connectionsMax_used_connectionsmax_connectionsset global max_connections = 1000;Too many connections/etc/my.cnf/etc/mysql/my.cnf[mysqld]max_connections = 1000/usr/lib/systemd/system/mysqld.servicemariadb.service[Service]LimitNOFILE=10000LimitNPROC=10000systemctl --system daemon-reloadsystemctl restart mysqldshow variablesmax_connectionsThreads_runningmax_connections