ERROR 1040 不是必须立刻扩容，应先确认是否真连满：用 socket 直连执行 SHOW VARIABLES LIKE 'max_connections' 和 SHOW STATUS LIKE 'Threads_connected'，若 Threads_connected 接近 max_connections 且 Threads_running 远小于前者，多为连接泄漏或未关闭；临时调大 max_connections 可救急但受限于系统 ulimit、Docker 配置及是否能连入，根本解法是合理配置应用层连接池（如 HikariCP、Druid）并确保 idle 超时短于 MySQL wait_timeout，同时校验内存占用避免 OOM。
直接说结论：ERROR 1040 不是必须立刻扩容，先确认是不是真爆了；临时调 max_connections 能救急，但不解决根本问题；连接池配置不当比服务器参数设低更常见。
怎么快速判断是不是真连满了
别急着改配置，先用 socket 直连（哪怕应用连不上）跑两条命令：
-
SHOW VARIABLES LIKE 'max_connections';看上限是多少（MySQL 5.7/8.0 默认只有151） -
SHOW STATUS LIKE 'Threads_connected';看当前已建连数，再对比Threads_running—— 如果后者远小于前者（比如Threads_connected=498但Threads_running=3），说明大量连接卡在Sleep状态，大概率是应用没正确 close 或连接池 leak
注意：Max_used_connections 值接近 max_connections 才算临界，80%~90% 就该预警，不是等报错才动。
临时调大 max_connections 的坑在哪
执行 SET GLOBAL max_connections = 1000; 确实能立刻缓解，但有三个硬限制：
- Linux 系统级文件描述符限制（
ulimit -n）可能拦住你，尤其 MariaDB；得同步改/usr/lib/systemd/system/mariadb.service里的LimitNOFILE - Docker 容器里默认没配
--ulimit，光改 MySQL 配置无效 - 如果已经连不上（连 DBA 账号都拒绝），这条命令根本执行不了——普通 MySQL 8.0.14+ 之前没管理员专用端口，这时候只能靠重启或系统层 kill 进程
永久生效要改哪些地方
编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，在 [mysqld] 段加：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
max_connections = 1000 max_user_connections = 200
为什么两个都设？max_user_connections 防止单个应用（比如某个微服务）占满所有连接，留余量给管理账号和其它服务。重启前务必检查：
- 配置文件语法是否正确（
mysqld --validate-config） - 配置是否被多个文件覆盖（
mysqld --verbose --help | grep "Default options"查加载顺序） - 如果是 Percona 或 MySQL 8.0.14+，可额外开
admin_address和service_connection_admin权限，留一条救命通道
连接池配置比 max_connections 更关键
很多“Too many connections”其实源于应用层连接池没控好：
- Spring Boot 的
HikariCP默认maximumPoolSize=10，但如果开了 50 个实例，每个连 10 个，就直接干到 500 连接——得按实例数 * 单实例池大小反推 MySQL 上限 - Node.js 的
mysql2如果没设connectionLimit，默认无限创建连接 - PHP-FPM 每个 worker 进程都可能建新连接，
pm.max_children× 单进程连接数 = 实际压向 MySQL 的连接数
真正稳定的方案是：MySQL max_connections ≥ 应用总连接池上限 × 1.2（留缓冲），且应用连接池 idle 超时必须短于 MySQL 的 wait_timeout（默认 8 小时），否则 Sleep 连接越积越多。
最常被忽略的一点：改完 max_connections 后，不检查内存占用。InnoDB 缓冲池、每个连接的 sort_buffer、join_buffer 都吃内存，盲目拉高可能触发 OOM Kill。用官方公式粗估：innodb_buffer_pool_size + (max_connections × (sort_buffer_size + join_buffer_size + read_buffer_size)) 别超物理内存 80%。
