MySQL最大连接数直接影响数据库能同时处理多少客户端请求。设得太低，高并发时会报“Too many connections”；设得太高，又可能耗尽内存或触发系统文件句柄限制。关键不是盲目调大，而是结合服务器资源、应用架构和实际负载来配置。
查看当前最大连接数
登录 MySQL 后执行：
SHOW VARIABLES LIKE 'max_connections';
返回值通常是 151（官方默认），部分发行版可能为 100 或 200。同时建议查一下历史峰值使用情况：
SHOW STATUS LIKE 'Max_used_connections';
如果这个值长期接近或等于 max_connections，说明当前设置已成瓶颈；若长期低于 10%，则可能设置偏高，浪费资源。
永久修改最大连接数（推荐）
修改配置文件才能确保重启后仍生效。路径因系统而异：
Linux：/etc/my.cnf 或 /etc/mysql/my.cnf Windows：MySQL 安装目录下的 my.ini在 [mysqld] 段内添加或修改：
max_connections = 500
保存后重启服务：
Linux：sudo systemctl restart mysql（或 mysqld） Windows：通过服务管理器重启 MySQL 服务注意：不要直接写成 2000+，需结合内存估算。每个连接至少占用 256KB 内存，1000 连接≈256MB；若设到 3000，最小内存开销已达 750MB，还需预留系统和其他进程空间。
临时调整与用户级限制
应急时可用 SQL 动态修改（无需重启）：
SET GLOBAL max_connections = 800;
但该值在服务重启后失效，仅适合短期扩容测试。
还可为特定用户加更细粒度控制：
查全局用户连接限制：SHOW VARIABLES LIKE 'max_user_connections'; 设全局默认值：SET GLOBAL max_user_connections = 50; 单独限制某用户（如 app_user）：ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 30;这对多租户或第三方接入场景很实用，防止单个应用占满全部连接。
配套优化不能少
光调 max_connections 不够，还需协同优化：
缩短空闲连接生命周期：SET GLOBAL wait_timeout = 300;（5 分钟自动断开非交互连接） 启用线程缓存减少创建开销：SET GLOBAL thread_cache_size = 16;（建议值为 CPU 核心数的 2 倍左右） 应用端必须用连接池（如 HikariCP），池大小不宜过大；常见经验公式是 CPU 核心数 × 2 + 1 定期用 SHOW PROCESSLIST; 检查是否有长时间 Sleep 状态的僵死连接不复杂但容易忽略。真正稳定的连接能力，来自服务端配置、系统资源和应用行为三者的匹配。
