应先查Max_used_connections而非直接调max_connections，因90%连接耗尽源于连接未释放、SQL慢或连接池配置错误；需结合ulimit、线程缓冲区及用户级限制综合排查。
别先改 max_connections，先查 Max_used_connections —— 90% 的“连接耗尽”根本不是上限低，而是连接没释放、SQL 慢、或应用池配错了。
怎么看自己到底需要多少连接
直接进 MySQL 执行这两条：
-
SHOW GLOBAL STATUS LIKE 'Max_used_connections';—— 看历史最高用过多少连接（不是当前值） -
SHOW VARIABLES LIKE 'max_connections';—— 看现在设了多少
如果前者长期稳定在 60～80，后者是默认 151，说明完全够用；如果前者接近后者（比如 145/151），才真要扩容。别按应用服务器数量 × 池大小拍脑袋算——实际并发远低于理论值，尤其有连接复用和超时机制时。
改了 max_connections 却不生效？大概率卡在系统限制上
MySQL 启动时会按 max_connections 预分配文件描述符（fd），每个连接至少占 1 个 fd，还要预留日志、表缓存等开销。若系统限制太低，MySQL 会默默截断到 ulimit 值，SHOW VARIABLES 显示的仍是配置值，但实际起效的是更小的那个。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 查当前限制：
ulimit -n（登录 MySQL 用户执行） - 要求：
ulimit -n ≥ max_connections + 200（留安全余量） - 永久生效：编辑
/etc/security/limits.conf，加两行：mysql soft nofile 4096mysql hard nofile 4096 - systemd 环境（CentOS 7+/Ubuntu 16.04+）还必须改服务单元：
编辑/usr/lib/systemd/system/mysqld.service，在[Service]下加：LimitNOFILE=10000
然后执行：systemctl --system daemon-reload && systemctl restart mysqld
调高之后内存爆了？重点盯这几个线程级 buffer
每个连接独享一份 sort_buffer_size、read_buffer_size、join_buffer_size 和 thread_stack。设成 2MB，300 个连接就吃掉 600MB 内存——而它们默认是 256KB，生产环境建议显式设为 256K～512K，别让监控里悄悄涨到 2M+。
- 查当前值：
SHOW VARIABLES LIKE '%buffer_size%';和SHOW VARIABLES LIKE 'thread_stack'; -
thread_stack默认 256KB 足够，不用动 - 其他 buffer 类参数，除非有明确优化需求，否则保持默认或统一设为
262144（256K） - 避免在会话级动态 SET 这些值——容易被应用代码无意放大
全局调高了，应用还是连不上？检查用户级连接限制
MySQL 允许对单个账号设更严的上限：MAX_USER_CONNECTIONS。即使 max_connections = 1000，如果应用账号被设成 MAX_USER_CONNECTIONS = 50，那最多只能连 50 个。
- 查账号限制：
SELECT User, Host, max_user_connections FROM mysql.user; - 临时改（当前会话）：
SET GLOBAL max_user_connections = 0;（0 表示不限） - 永久改（推荐）：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 200; - 改完记得
FLUSH PRIVILEGES;
真正难处理的从来不是数字本身，而是连接泄漏、慢查询堵住连接、或连接池空闲连接没及时回收——这些不会因为 max_connections 调高就自动消失。先确保 wait_timeout 设为 60～300 秒，再确认应用用了 HikariCP 并开了 leakDetectionThreshold，比盲目拉高上限管用得多。
