MySQL并发连接数需匹配业务负载与硬件资源，盲目调高max_connections易致内存耗尽；应通过SHOW STATUS和SHOW PROCESSLIST分析实时连接状态，结合历史峰值与空闲连接情况合理设置，并配套调整wait_timeout等参数，同时重视应用层连接池管理与资源释放。
MySQL 的并发连接数不是越多越好，关键在于匹配业务实际负载、硬件资源和连接使用模式。盲目调高 max_connections 可能导致内存耗尽、上下文切换加剧，反而降低性能。
看懂当前连接真实压力
别只盯着“最大允许连接数”，先查清实际用了多少、怎么用的：
-
实时连接状态：执行
SHOW STATUS LIKE 'Threads_connected';查当前活跃连接数；SHOW PROCESSLIST;看具体在做什么（重点关注Sleep、Query、Sending data状态） -
历史峰值参考：检查慢查询日志或监控系统（如 Prometheus + MySQL exporter）中
threads_connected的 95 分位值，比单次快照更可靠 -
注意空闲连接堆积：大量
Sleep状态且持续时间长，大概率是应用未正确释放连接（如没 close() 或连接池配置不合理），这不是数据库要扩容，而是应用要修复
合理设置 max_connections
默认值（通常 151）对多数中小业务偏高，对高并发小事务场景又可能不足。建议按以下逻辑估算：
-
基础公式参考：
max_connections ≈ (可用内存 − MySQL 固定开销) ÷ 单连接内存占用 -
单连接内存估算：主要看
sort_buffer_size、join_buffer_size、read_buffer_size等会为每个连接分配的内存（非全局共享）。例如设为 2MB/连接，1000 连接就需额外 2GB 内存 - 推荐起步值：Web 应用常见连接池大小为 20–50，数据库端设为池大小 × 1.5～2 倍较稳妥（如应用配了 30 连接池，MySQL 设 60–80 即可）；OLAP 或批处理类可临时调高，但务必配合超时控制
必须配套的关键参数
光调 max_connections 不够，这些参数不配好，连接数再高也白搭：
- wait_timeout 和 interactive_timeout：控制空闲连接自动断开时间，默认 28800 秒（8 小时）太长。建议设为 300–600 秒（5–10 分钟），避免 Sleep 连接长期占位
-
max_connect_errors：防暴力探测或网络异常导致的连接拒绝，建议保持默认 100 或略调高，配合
FLUSH HOSTS清理 - connect_timeout：设为 10 秒内，避免半开连接长时间挂起
应用层比数据库层更重要
真正决定并发能力的，往往不在 MySQL 本身，而在应用如何用连接：
- 用连接池（如 HikariCP、Druid），并合理配置
minimumIdle、maximumPoolSize、connectionTimeout - 确保每次数据库操作后显式归还连接（try-with-resources 或 finally 中 close）
- 避免长事务、大结果集查询阻塞连接；复杂计算尽量移到应用层或用异步任务
- 读多写少场景，考虑加从库分担只读请求，降低主库连接压力
不复杂但容易忽略：调参前先观察，调完后盯住内存和 CPU，连接数只是表象，背后是资源分配与使用效率的问题。
